Starting from en entry point in a shareable image from DCL.

[Jan-Erik Soderholm]

Hi.

First, don't ask *why* things are as they are, this is a
30+ year old system and I'm sure they had some good reason
to build it as it is when run on some VAX 11/xxx system...

Envir:
AS DS20e
OpenVMS 8.2
Language Cobol

We have some applications that are linked as a shareable image:

$ LINK/EXE=MK_ARK:MK.EXE/SHARE -
MK_ARK:aaa.OBJ,-
MK_ARK:bbb.OBJ,-
MK_ARK:ccc.OBJ,-
SYS$INPUT:/OPTION
MKSHARE/SHARE
SYMBOL_VECTOR=(aaa=PROCEDURE,-
bbb=PROCEDURE,-
ccc=PROCEDURE)

(MKSHARE is another shareable image, but that is not an issue.)

This apps are then run from our menu system that does know
how to start from a specific entry point/vector. You configure
the menu item with the name of the image (MK.EXE) and the name
of the entry point/vector (like aaa, bbb or ccc above).

The problem is that on our test system we don't have
access to that menu system. I have not found any easy
way to RUN from the DCL prompt from one of these
entry points/vectors in the shearable image.

What I'm doing at the moment when there is a need for
some testing of a specific application (like aaa, bbb
or ccc above), is to relink it as a stand-alone EXE.

But of course, that will not be *exactly* the same test
environment as the one running in prod.

So, what are the options to call/run from one of these
entry points/vectors in the shareable EXE ? Do we have
to build a spearate EXE that only does a CALL to one
of these apps (aaa, bbb or ccc) ?

Thanks,
Jan-Erik.

[hb]

Post by Jan-Erik Soderholm
So, what are the options to call/run from one of these
entry points/vectors in the shareable EXE ? Do we have
to build a spearate EXE that only does a CALL to one
of these apps (aaa, bbb or ccc) ?

Writing a main image, which links against the shareable one and which
calls the "apps" is probably the right and best solution.

The other options are hacks or require changes to the shareable image.
You can patch/abs the image and swap the entry point (you need to know
where that is in the image and what to put there - the latter should be
in the linker map). You can add your main to the shareable image and do
the same calls as if in the separate image.

[Joukj]

Post by Jan-Erik Soderholm
Hi.
First, don't ask *why* things are as they are, this is a
30+ year old system and I'm sure they had some good reason
to build it as it is when run on some VAX 11/xxx system...
AS DS20e
OpenVMS 8.2
Language Cobol
$ LINK/EXE=MK_ARK:MK.EXE/SHARE -
MK_ARK:aaa.OBJ,-
MK_ARK:bbb.OBJ,-
MK_ARK:ccc.OBJ,-
SYS$INPUT:/OPTION
MKSHARE/SHARE
SYMBOL_VECTOR=(aaa=PROCEDURE,-
bbb=PROCEDURE,-
ccc=PROCEDURE)
(MKSHARE is another shareable image, but that is not an issue.)
This apps are then run from our menu system that does know
how to start from a specific entry point/vector. You configure
the menu item with the name of the image (MK.EXE) and the name
of the entry point/vector (like aaa, bbb or ccc above).
The problem is that on our test system we don't have
access to that menu system. I have not found any easy
way to RUN from the DCL prompt from one of these
entry points/vectors in the shearable image.
What I'm doing at the moment when there is a need for
some testing of a specific application (like aaa, bbb
or ccc above), is to relink it as a stand-alone EXE.
But of course, that will not be *exactly* the same test
environment as the one running in prod.
So, what are the options to call/run from one of these
entry points/vectors in the shareable EXE ? Do we have
to build a spearate EXE that only does a CALL to one
of these apps (aaa, bbb or ccc) ?
Thanks,
Jan-Erik.

You need create a small program that
1) gets the location in the shareable image using
LIB$FIND_IMAGE_SYMBOL
2) Call the procedure using LIB$CALLG


Regards
Jouk

[V***@SendSpamHere.ORG]

Post by Jan-Erik Soderholm
Hi.
First, don't ask *why* things are as they are, this is a
30+ year old system and I'm sure they had some good reason
to build it as it is when run on some VAX 11/xxx system...
AS DS20e
OpenVMS 8.2
Language Cobol
$ LINK/EXE=MK_ARK:MK.EXE/SHARE -
MK_ARK:aaa.OBJ,-
MK_ARK:bbb.OBJ,-
MK_ARK:ccc.OBJ,-
SYS$INPUT:/OPTION
MKSHARE/SHARE
SYMBOL_VECTOR=(aaa=PROCEDURE,-
bbb=PROCEDURE,-
ccc=PROCEDURE)
(MKSHARE is another shareable image, but that is not an issue.)
This apps are then run from our menu system that does know
how to start from a specific entry point/vector. You configure
the menu item with the name of the image (MK.EXE) and the name
of the entry point/vector (like aaa, bbb or ccc above).
The problem is that on our test system we don't have
access to that menu system. I have not found any easy
way to RUN from the DCL prompt from one of these
entry points/vectors in the shearable image.
What I'm doing at the moment when there is a need for
some testing of a specific application (like aaa, bbb
or ccc above), is to relink it as a stand-alone EXE.
But of course, that will not be *exactly* the same test
environment as the one running in prod.
So, what are the options to call/run from one of these
entry points/vectors in the shareable EXE ? Do we have
to build a spearate EXE that only does a CALL to one
of these apps (aaa, bbb or ccc) ?
Thanks,
Jan-Erik.

LIB$FIND_IMAGE_SYMBOL

[Stephen Hoffman]

So, what are the options to call/run from one of these entry
points/vectors in the shareable EXE ? Do we have to build a spearate
EXE that only does a CALL to one of these apps (aaa, bbb or ccc) ?

Either port the menu environment to the test servers (which would
better replicate the production environment), or add shims into the
code in the shareable to allow easier testing, or use logical name
image redirection or lib$find_image_symbol or the C dynamic loader
routines or a static link against the shareable image to find and
activate the target code from within a testing-related stub main image.

Possibly a stub main image that uses C argument processing or CLI
callbacks to provide the "wrapper" that you're seemingly looking for.

DCL does not have symbol-level constructs for executables; RUN and the
Foreign Commands (is that a VMS nerd band?) are largely what you have
available in DCL for image image invocation.

[Jan-Erik Soderholm]

So, what are the options to call/run from one of these entry
points/vectors in the shareable EXE ? Do we have to build a spearate EXE
that only does a CALL to one of these apps (aaa, bbb or ccc) ?

Either port the menu environment to the test servers (which would better
replicate the production environment), or add shims into the code in the
shareable to allow easier testing, or use logical name image redirection or
lib$find_image_symbol or the C dynamic loader routines or a static link
against the shareable image to find and activate the target code from
within a testing-related stub main image.
Possibly a stub main image that uses C argument processing or CLI callbacks
to provide the "wrapper" that you're seemingly looking for.
DCL does not have symbol-level constructs for executables; RUN and the
Foreign Commands (is that a VMS nerd band?) are largely what you have
available in DCL for image image invocation.

OK, thanks!

We can't run (or "port") the menu handler to the test box, it is
a license issue, and the issuer is long gone...

OK, a small Cobol routine that just makes a CALL to the
entry vectors will be tried. B.t.w, isn't the find_image_symbol
stuff done at link time, if the shareable is included/referenced
in the link option file?

I do not think we use the lib$find_image_symbol call in our
apps that calls other entries in the same shareable...

Jan-Erik.

[Stephen Hoffman]

We can't run (or "port") the menu handler to the test box, it is a
license issue, and the issuer is long gone...

There can be paths to resolve that, so long as there's some entity
around that acknowledges ownership of the rubble of the issuer.

OK, a small Cobol routine that just makes a CALL to the entry vectors
will be tried.

That's a stub. Static linked.

B.t.w, isn't the find_image_symbol stuff done at link time, if the
shareable is included/referenced in the link option file?

No. lib$find_image_symbol finds and loads and image-activates the
specified shareable image and the specified symbol dynamically; at
run-time.

Contrast this with the static link-time approach you're using with that
COBOL stub main executable image.

I do not think we use the lib$find_image_symbol call in our apps that
calls other entries in the same shareable...

I would not really expect that, either. COBOL 2002 added pointer
support and related, but VMS lacks a compiler with support for that
standard.

[John Reagan]

Post by Stephen Hoffman
COBOL 2002 added pointer
support and related, but VMS lacks a compiler with support for that
standard.

As extensions, OpenVMS COBOL has "USAGE IS POINTER" and "USAGE IS POINTER-64". The pointer support doesn't let you do much other than carry them around from one place to another.

[Bill Gunshannon]

Post by John Reagan

Post by Stephen Hoffman
COBOL 2002 added pointer
support and related, but VMS lacks a compiler with support for that
standard.

As extensions, OpenVMS COBOL has "USAGE IS POINTER" and "USAGE IS
POINTER-64". The pointer support doesn't let you do much other
than carry them around from one place to another.

Having played with this feature quite a bit in GNU COBOL I feel safe
saying the primary reason it was added was to make it easier to inteface
with other languages, like C, that have this thing about passing things
around using pointers. I wrote a COBOL Library for accessing Postgres
(in COBOL) in order to better hide the ugliness needed to do it.

bill

[hb]

Post by Jan-Erik Soderholm
OK, a small Cobol routine that just makes a CALL to the
entry vectors will be tried. B.t.w, isn't the find_image_symbol
stuff done at link time, if the shareable is included/referenced
in the link option file?

No, the linker resolves (global) symbols, from objects and shareable
images. For that, the linker opens and reads the object and image files,
they are not activated. The linker only needs to resolve symbols for the
image it links, that's just one level of dependencies.
Lib$find_image_symbol activates the shareable image with the given
symbol. Activting an image also means to activate all shareable images
that the image depends on.

[Jan-Erik Soderholm]

Post by hb

Post by Jan-Erik Soderholm
OK, a small Cobol routine that just makes a CALL to the
entry vectors will be tried. B.t.w, isn't the find_image_symbol
stuff done at link time, if the shareable is included/referenced
in the link option file?

No, the linker resolves (global) symbols, from objects and shareable
images. For that, the linker opens and reads the object and image files,
they are not activated. The linker only needs to resolve symbols for the
image it links, that's just one level of dependencies.
Lib$find_image_symbol activates the shareable image with the given symbol.
Activting an image also means to activate all shareable images that the
image depends on.

What I ment was that the linker "finds" the routines in the
shareable at link time, just as Lib$find_image_symbol finds
it at run time.

Anyway, I get it. Currenly doing a small stubb to call our app...

Jan-Erik.

[JF Mezei]

Post by Jan-Erik Soderholm
What I ment was that the linker "finds" the routines in the
shareable at link time, just as Lib$find_image_symbol finds
it at run time.

static linker means that you have to preserve your entry point
locations. so when you update the shareable image, you need to be
careful (hence use of transfer vectors at top of image).

with lib$find_image_symbol, you have more freedom to update shareable
image and not worry about location of entry points.


lib$find_image_symbol also allows you to choose a shareable image at run
time. (choose approriate shareable image corresponding to device entered
by user).

[hb]

On 05/15/2014 09:41 AM, JF Mezei wrote:

As usual, there are pros and cons.

Post by JF Mezei
static linker means that you have to preserve your entry point
locations. so when you update the shareable image, you need to be
careful (hence use of transfer vectors at top of image).

OP said "test system". I don't know the details, but if the symbol
vector entries - OP said Alpha - changed, it should be possible to
relink the main test image.

Post by JF Mezei
with lib$find_image_symbol, you have more freedom to update shareable
image and not worry about location of entry points.

True and there is more freedom with GSMATCH: lib$find_image_symbol can't
and doesn't check it.

Post by JF Mezei
lib$find_image_symbol also allows you to choose a shareable image at run
time. (choose approriate shareable image corresponding to device entered
by user).

Same with statically linked images: at run time define a logical
pointing to whatever shareable image you want to be activated.

[JF Mezei]

Post by hb
Same with statically linked images: at run time define a logical
pointing to whatever shareable image you want to be activated.

Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.

With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.

(context: application decides whcih shareable image to use based on
input from customer).

[Jan-Erik Soderholm]

Post by JF Mezei

Post by hb
Same with statically linked images: at run time define a logical
pointing to whatever shareable image you want to be activated.

Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.

What is what I guess he ment (and also as I read it), you define the
logical, *then* you run our main image, of course.

Post by JF Mezei
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.
(context: application decides whcih shareable image to use based on
input from customer).

[Paul Sture]

Post by Jan-Erik Soderholm

Post by JF Mezei

Post by hb
Same with statically linked images: at run time define a logical
pointing to whatever shareable image you want to be activated.

Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.

What is what I guess he ment (and also as I read it), you define the
logical, *then* you run our main image, of course.

That's how I understood it too. We used to use group logicals here, so
could run different versions on the same machine (e.g. test and development).

[hb]

Post by JF Mezei

Post by hb
Same with statically linked images: at run time define a logical

Post by hb
pointing to whatever shareable image you want to be activated.

Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.

Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.

[V***@SendSpamHere.ORG]

Post by hb

Post by JF Mezei

Post by hb
Same with statically linked images: at run time define a logical

Post by hb
pointing to whatever shareable image you want to be activated.

Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.

Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.

And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)

[David Froble]

Post by V***@SendSpamHere.ORG

Post by hb

Post by JF Mezei

Post by hb
Same with statically linked images: at run time define a logical

Post by hb
pointing to whatever shareable image you want to be activated.

Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.

Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.

And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)

Ya know, I've never used this capability, never had the need. Also am
not familiar with it.

But, it occurs to me, in certain circumstances, it could be a security
issue.

As an example, you have a RTL with some routines that are called only
from within the RTL, and say one of the routines is set up to perform
some privileged operation. With this capability, someone could find the
entry point and invoke the routine doing the privileged stuff.

Or am I missing something rather basic?

[JF Mezei]

Post by David Froble

Post by V***@SendSpamHere.ORG
And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)

Ya know, I've never used this capability, never had the need. Also am
not familiar with it.

In a Lord of the Rings analogy:

You live on the surface (user mode)
Mr VAXman lives in Middle Earth (kernel mode)

:-)

[V***@SendSpamHere.ORG]

Post by JF Mezei

Post by David Froble

Post by V***@SendSpamHere.ORG
And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)

Ya know, I've never used this capability, never had the need. Also am
not familiar with it.

You live on the surface (user mode)
Mr VAXman lives in Middle Earth (kernel mode)

Save that both $IMGACT and $IMGFIX can be used, quite successfully too, in
user mode.

[V***@SendSpamHere.ORG]

Post by David Froble

Post by V***@SendSpamHere.ORG

Post by hb

Post by JF Mezei

Post by hb
Same with statically linked images: at run time define a logical

Post by hb
pointing to whatever shareable image you want to be activated.

Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.

Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.

And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)

Ya know, I've never used this capability, never had the need. Also am
not familiar with it.
But, it occurs to me, in certain circumstances, it could be a security
issue.
As an example, you have a RTL with some routines that are called only
from within the RTL, and say one of the routines is set up to perform
some privileged operation. With this capability, someone could find the
entry point and invoke the routine doing the privileged stuff.
Or am I missing something rather basic?

You can't get there from here. No more insecure than invoking a routine
that was mapped using LIB$FIND_IMAGE_SYMBOL. Unless a process possesses
the privileges to perform a privileged function, mapping an image into a
process that performs a privileged function[*] will fail with SS$_NOPRIV
when that privileged function is exercised.

[*] Notwithstanding images with a privilege vector; however, VMS enforces
that these be installed, an action which required privileges to perform.

[David Froble]

Post by V***@SendSpamHere.ORG

Post by David Froble

Post by V***@SendSpamHere.ORG

Post by hb

Post by JF Mezei

Post by hb
Same with statically linked images: at run time define a logical

Post by hb
pointing to whatever shareable image you want to be activated.

Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.

Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.

And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)

Ya know, I've never used this capability, never had the need. Also am
not familiar with it.
But, it occurs to me, in certain circumstances, it could be a security
issue.
As an example, you have a RTL with some routines that are called only
from within the RTL, and say one of the routines is set up to perform
some privileged operation. With this capability, someone could find the
entry point and invoke the routine doing the privileged stuff.
Or am I missing something rather basic?

You can't get there from here. No more insecure than invoking a routine
that was mapped using LIB$FIND_IMAGE_SYMBOL. Unless a process possesses
the privileges to perform a privileged function, mapping an image into a
process that performs a privileged function[*] will fail with SS$_NOPRIV
when that privileged function is exercised.
[*] Notwithstanding images with a privilege vector; however, VMS enforces
that these be installed, an action which required privileges to perform.

I wasn't too specific. It was LIB$FIND_IMAGE_SYMBOL that I was
referring to.

If the RTL is installed with privs, and the routine does a CMEXEC or
CMKRNL to perform some operation, then if the routine is invoked from
something that finds the symbol, then would that program without prive
still be able to perform the CM????

I have that specific case, in a RTL that needed SYSLCK but the users
would not have that priv.

Maybe I should get off my lazy ass and RTFM ....

[V***@SendSpamHere.ORG]

Post by David Froble

Post by V***@SendSpamHere.ORG

Post by David Froble

Post by V***@SendSpamHere.ORG

Post by hb

Post by JF Mezei

Post by hb
Same with statically linked images: at run time define a logical

Post by hb
pointing to whatever shareable image you want to be activated.

Nop. With static linking, the resolution of the logical is made at image
activation time, so the application cannot change it on the fly and open
a different shareable image.
With lib$find_image_symbol, you can because the shareable image is not
resolved at image activation before your program's logic can decide
which shareable image to open.

Yes, you are right, that's not the same. With lib$find_image_symbol you
are more flexible.

And, with $IMGACT/$IMGFIX you have even more flexibilty. ;)

Ya know, I've never used this capability, never had the need. Also am
not familiar with it.
But, it occurs to me, in certain circumstances, it could be a security
issue.
As an example, you have a RTL with some routines that are called only
from within the RTL, and say one of the routines is set up to perform
some privileged operation. With this capability, someone could find the
entry point and invoke the routine doing the privileged stuff.
Or am I missing something rather basic?

You can't get there from here. No more insecure than invoking a routine
that was mapped using LIB$FIND_IMAGE_SYMBOL. Unless a process possesses
the privileges to perform a privileged function, mapping an image into a
process that performs a privileged function[*] will fail with SS$_NOPRIV
when that privileged function is exercised.
[*] Notwithstanding images with a privilege vector; however, VMS enforces
that these be installed, an action which required privileges to perform.

I wasn't too specific. It was LIB$FIND_IMAGE_SYMBOL that I was
referring to.
If the RTL is installed with privs, and the routine does a CMEXEC or
CMKRNL to perform some operation, then if the routine is invoked from
something that finds the symbol, then would that program without prive
still be able to perform the CM????

When you can INSTALL an RTL with privileges, you let me know.

Post by David Froble
I have that specific case, in a RTL that needed SYSLCK but the users
would not have that priv.

IF an RTL requires SYSLCK privilege to, for some controlled reason within
that RTL, perform its task, you create a privileged shareable image (user
written system services) and install it as such. The image invoking it,
regardless of the user's lack of a necessary specific privilege, can then
perform its task.

Post by David Froble
Maybe I should get off my lazy ass and RTFM ....

...and then, RRTFM.

[David Froble]

Post by V***@SendSpamHere.ORG

Post by David Froble
If the RTL is installed with privs, and the routine does a CMEXEC or
CMKRNL to perform some operation, then if the routine is invoked from
something that finds the symbol, then would that program without prive
still be able to perform the CM????

When you can INSTALL an RTL with privileges, you let me know.

Yeah, it just shows how pervasive the senility has progressed ..

DISK$VMS072:<SYS0.SYSLIB>.EXE
DASRTL;13 Open Hdr Shar Prot Lnkbl

This is how the RTL is installed.

Now, the following was written in 1984, and it's been over 10 years
since I did any MACRO-32. Take pity, my head hurts ..

;+
; The following routines will run in EXEC mode
;-

XVECTOR ROUTINE=DAS_VINIT,MODE=EXEC,UNIVERSAL=NO

 .PAGE
.SUBTITLE Privileged library vector

.PSECT PLV,CON,LCL,NOEXE,PIC,RD,REL,SHR,NOWRT,VEC,PAGE

.LONG PLV$C_TYP_CMOD ; This is a change mode vector
.LONG SYS$K_VERSION ; System version
.LONG 0 ; No kernel mode dispatcher
.LONG DSPEXEC - . ; Offset to EXEC mode dispatcher
.LONG 0 ; No rundown service
.LONG 0 ; Reserved
.LONG 0 ; No RMS dispatcher
.LONG 0 ; PIC image

 .PAGE
.SUBTITLE Executive mode dispatcher

;++
;
; Abstract:
;
; This is the executive mode dispatcher invoked by the VMS
; executive mode change mode dispatcher when a system service code
; (index) is not recognized by it.
;
; Input parameters:
;
; (SP) = Return address if index is not ours
; R0 = Change modex index
; AP = Argument pointer
; FP = Call frame for exit
;
;--

.GLOBAL DSPEXEC

DSPEXEC:

MNEGL R0,R0 ; Make index positive
BGTR 200$ ; Continue if GT zero
100$: RSB ; Return, not this dispatcher
200$: CASEL R0,#1,#-DAS_MAXEXEC ; Dispatch on index

000$: .WORD DAS_VINIT + 2 - 000$

RSB

Post by V***@SendSpamHere.ORG

Post by David Froble
I have that specific case, in a RTL that needed SYSLCK but the users
would not have that priv.

IF an RTL requires SYSLCK privilege to, for some controlled reason within
that RTL, perform its task, you create a privileged shareable image (user
written system services) and install it as such. The image invoking it,
regardless of the user's lack of a necessary specific privilege, can then
perform its task.

Post by David Froble
Maybe I should get off my lazy ass and RTFM ....

...and then, RRTFM.

Yeah, but then my head would hurt worse.

:-)

As I wrote, I've never used LIB$FIND_IMAGE_SYMBOL, so I'm pretty clueless.

What I've wondered is whether that EXEC mode routine can be used by
finding the symbol in the RTL. After looking at things, I'm thinking
not, but as I wrote, it's been a long time, and if you don't do MACRO
constantly, you don't do it well, or at all.

[V***@SendSpamHere.ORG]

Post by David Froble

Post by V***@SendSpamHere.ORG

Post by David Froble
If the RTL is installed with privs, and the routine does a CMEXEC or
CMKRNL to perform some operation, then if the routine is invoked from
something that finds the symbol, then would that program without prive
still be able to perform the CM????

When you can INSTALL an RTL with privileges, you let me know.

Yeah, it just shows how pervasive the senility has progressed ..

The mind is the second thing to go, so I've been told.

Post by David Froble
DISK$VMS072:<SYS0.SYSLIB>.EXE
DASRTL;13 Open Hdr Shar Prot Lnkbl
This is how the RTL is installed.
Now, the following was written in 1984, and it's been over 10 years
since I did any MACRO-32. Take pity, my head hurts ..
;+
; The following routines will run in EXEC mode
;-
XVECTOR ROUTINE=DAS_VINIT,MODE=EXEC,UNIVERSAL=NO
 .PAGE
.SUBTITLE Privileged library vector
.PSECT PLV,CON,LCL,NOEXE,PIC,RD,REL,SHR,NOWRT,VEC,PAGE
.LONG PLV$C_TYP_CMOD ; This is a change mode vector
.LONG SYS$K_VERSION ; System version
.LONG 0 ; No kernel mode dispatcher
.LONG DSPEXEC - . ; Offset to EXEC mode dispatcher
.LONG 0 ; No rundown service
.LONG 0 ; Reserved
.LONG 0 ; No RMS dispatcher
.LONG 0 ; PIC image
 .PAGE
.SUBTITLE Executive mode dispatcher
;++
;
;
; This is the executive mode dispatcher invoked by the VMS
; executive mode change mode dispatcher when a system service code
; (index) is not recognized by it.
;
;
; (SP) = Return address if index is not ours
; R0 = Change modex index
; AP = Argument pointer
; FP = Call frame for exit
;
;--
.GLOBAL DSPEXEC
MNEGL R0,R0 ; Make index positive
BGTR 200$ ; Continue if GT zero
100$: RSB ; Return, not this dispatcher
200$: CASEL R0,#1,#-DAS_MAXEXEC ; Dispatch on index
000$: .WORD DAS_VINIT + 2 - 000$
RSB

Post by V***@SendSpamHere.ORG

Post by David Froble
I have that specific case, in a RTL that needed SYSLCK but the users
would not have that priv.

IF an RTL requires SYSLCK privilege to, for some controlled reason within
that RTL, perform its task, you create a privileged shareable image (user
written system services) and install it as such. The image invoking it,
regardless of the user's lack of a necessary specific privilege, can then
perform its task.

Post by David Froble
Maybe I should get off my lazy ass and RTFM ....

...and then, RRTFM.

Yeah, but then my head would hurt worse.
:-)
As I wrote, I've never used LIB$FIND_IMAGE_SYMBOL, so I'm pretty clueless.
What I've wondered is whether that EXEC mode routine can be used by
finding the symbol in the RTL. After looking at things, I'm thinking
not, but as I wrote, it's been a long time, and if you don't do MACRO
constantly, you don't do it well, or at all.

Well, this is VMS internals, not necessarily Macro. These things can also
be done in Bliss, some HLLs or C since the advent of OpenVMS Alpha.

[Paul Sture]

Post by V***@SendSpamHere.ORG

Post by David Froble
Yeah, it just shows how pervasive the senility has progressed ..

The mind is the second thing to go, so I've been told.

Oh, I thought it was the third thing.

After the hair and the teeth, of course.

[V***@SendSpamHere.ORG]

Post by Paul Sture

Post by V***@SendSpamHere.ORG

Post by David Froble
Yeah, it just shows how pervasive the senility has progressed ..

The mind is the second thing to go, so I've been told.

Oh, I thought it was the third thing.
After the hair and the teeth, of course.

In that case, I still must have my mind as I have both teeth and plenty of
hair! Loading Image...

So, I should be wary of toothless baldies?

[JF Mezei]

In that case, I still must have my mind as I have both teeth ...

If the mind is associated with how many teeth you have left, bragging
about still having 2 teeth says a lot about how much of a mind you
started off with :-) No wonder you can't rise above kernel mode :-)

[V***@SendSpamHere.ORG]

Post by JF Mezei

In that case, I still must have my mind as I have both teeth ...

If the mind is associated with how many teeth you have left, bragging
about still having 2 teeth says a lot about how much of a mind you
started off with :-) No wonder you can't rise above kernel mode :-)

Au contraire, I still possess all 32 bit(e)s.

[David Froble]

Post by V***@SendSpamHere.ORG
The mind is the second thing to go, so I've been told.

I think you may be right ...

#1, check

#2, check

Now I got to wonder what #3 will be.

[m***@gmail.com]

Here's one way to do it

status = lib$find_image_symbol ("MENU_APP:MK", <entry_pt_name>, &ret_address)

Just define logical MENU_APP to point to whatever directory you want to use. It cannot be a directory specification. The documentation for lib$find_image_symbol lets you specify a related filename as per RMS, but why bother if your logical points to where you want to be?

When you have the function address you call that, passing the appropriate parameters for that routine.

Where I work we use this kind of thing all the time. It saves having to link routines against each other; the only thing we do link against is our routine that does the LIB$FIND_IMAGE_SYMBOL. We tell it the name of the entry point and it looks up a table to find the executable image that contains that entry point. We also use it for the recent SSL upgrade (to v1.4?) where we call SSL routines from our application, our VMS version being 8.3 and using v1.3 itself.

[hb]

Post by m***@gmail.com
Just define logical MENU_APP to point to whatever directory you want

to use. It cannot be a directory specification. The documentation for
lib$find_image_symbol lets you specify a related filename as per RMS,
but why bother if your logical points to where you want to be?

It depends on when you define the logical. If you define it before you
run your main, then there is no benefit using lib$find_image_symbol (for
an image with transfer/symbol vectors). The only difference is in using
more cpu time and resources. If you define the logical from your main,
depending on user input, then you have an additional level of
flexibility (which you have to pay for). - I misunderstood the "at run
time" as specifying the shareable image before activating the main image.

You pay for reading the global symbol table from the image file. The
image activator doesn't need/use these symbols. As you probably know,
after linking your main image with a shareable one, you can relink your
shareable image without the symbol table (for whatever reason, for
example to make the image file smaller). Image activation still works,
but lib$find_image_symbol does not.

That also raises the question how you get to the symbols after using
just $imgact/$imgfix. OK, there was a :-)