Question about INSTALLing shared images - VMS

This is a discussion on Question about INSTALLing shared images - VMS ; Season's Greetings (I actually saw this in big letters hanging from the ceiling of a Wegmans supermarket!) My apologies if this is a dumb question, but I want to be 100% certain. (Hey, at least it's on topic!!!) When you ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

Thread: Question about INSTALLing shared images

  1. Question about INSTALLing shared images

    Season's Greetings (I actually saw this in big letters hanging from
    the ceiling of a Wegmans supermarket!)

    My apologies if this is a dumb question, but I want to be 100%
    certain. (Hey, at least it's on topic!!!)

    When you INSTALL an executable as a shared image, can it be any
    executable? I once discussed this with my developer for a program run
    by multiple traders and he said we'd have to check for traders
    stepping on each other, so to speak. So my question is: Doesn't VMS
    automatically provide each process running shared executable its own
    private data area in memory or does the program have to be explicitly
    written with the assumption that it will be installed shared?

    Thanks

    AEF

  2. Re: Question about INSTALLing shared images

    AEF wrote:
    > Season's Greetings (I actually saw this in big letters hanging from
    > the ceiling of a Wegmans supermarket!)
    >
    > My apologies if this is a dumb question, but I want to be 100%
    > certain. (Hey, at least it's on topic!!!)
    >
    > When you INSTALL an executable as a shared image, can it be any
    > executable? I once discussed this with my developer for a program run
    > by multiple traders and he said we'd have to check for traders
    > stepping on each other, so to speak. So my question is: Doesn't VMS
    > automatically provide each process running shared executable its own
    > private data area in memory or does the program have to be explicitly
    > written with the assumption that it will be installed shared?
    >
    > Thanks
    >
    > AEF


    My recollection is that the writeable areas are unique while the read
    only stuff (code, constants, etc.) is shared.

    ISTR that the subject is covered in some detail in the FM. Go thou, and
    RTFM.


  3. Re: Question about INSTALLing shared images

    AEF wrote:
    > Season's Greetings (I actually saw this in big letters hanging from
    > the ceiling of a Wegmans supermarket!)
    >
    > My apologies if this is a dumb question, but I want to be 100%
    > certain. (Hey, at least it's on topic!!!)
    >
    > When you INSTALL an executable as a shared image, can it be any
    > executable? I once discussed this with my developer for a program run
    > by multiple traders and he said we'd have to check for traders
    > stepping on each other, so to speak. So my question is: Doesn't VMS
    > automatically provide each process running shared executable its own
    > private data area in memory or does the program have to be explicitly
    > written with the assumption that it will be installed shared?
    >
    > Thanks
    >
    > AEF



    The data area of a program is by default noshare and the executable is
    share so installing a program shared allows the code to be shared but
    each user has their own data area unless the program is written to have
    a shared data area. Sharing data between processes in a program is a
    rare special circumstance in the business apps I have seen.

    This is a bit of a simplification as there are many linker and install
    options. I'm sure others in this group can supply more detailed info.

    Jeff Coffield

  4. Re: Question about INSTALLing shared images

    AEF wrote:

    > Season's Greetings (I actually saw this in big letters hanging from
    > the ceiling of a Wegmans supermarket!)
    >
    > My apologies if this is a dumb question, but I want to be 100%
    > certain. (Hey, at least it's on topic!!!)
    >
    > When you INSTALL an executable as a shared image, can it be any
    > executable? I once discussed this with my developer for a program run
    > by multiple traders and he said we'd have to check for traders
    > stepping on each other, so to speak. So my question is: Doesn't VMS
    > automatically provide each process running shared executable its own
    > private data area in memory or does the program have to be explicitly
    > written with the assumption that it will be installed shared?
    >
    > Thanks
    >
    > AEF


    If the multiple instances of an app write to a single shared file,
    then the app needs to lock the shared file before and unlock it after
    writing to that file; else, the copies may corrupt the file.
    --
    Cheers, Bob

  5. Re: Question about INSTALLing shared images

    AEF wrote:

    > When you INSTALL an executable as a shared image, can it be any
    > executable?


    No. You can't install a OS-X executable on VMS. :-)

    If your application is written in C, there are certain constructs with
    public variables which may prevent it from being installed/shared if I
    remember correctly. If I recall, the "extern" type of declaration is not
    compatible with installing image/shared.

    (Or this could be a linker issue not allowing /SHARED to be used in such
    circumstances).

    Similarly, your executable must be linked/NOTRACEBACK when it is
    installed/shared.

    This is all from fairly distant memory with no parity bit.

  6. Re: Question about INSTALLing shared images

    On Dec 26, 11:33 am, "Richard B. Gilbert"
    wrote:
    > AEF wrote:
    > > Season's Greetings (I actually saw this in big letters hanging from
    > > the ceiling of a Wegmans supermarket!)

    >
    > > My apologies if this is a dumb question, but I want to be 100%
    > > certain. (Hey, at least it's on topic!!!)

    >
    > > When you INSTALL an executable as a shared image, can it be any
    > > executable? I once discussed this with my developer for a program run
    > > by multiple traders and he said we'd have to check for traders
    > > stepping on each other, so to speak. So my question is: Doesn't VMS
    > > automatically provide each process running shared executable its own
    > > private data area in memory or does the program have to be explicitly
    > > written with the assumption that it will be installed shared?

    >
    > > Thanks

    >
    > > AEF

    >
    > My recollection is that the writeable areas are unique while the read
    > only stuff (code, constants, etc.) is shared.


    Thanks!

    >
    > ISTR that the subject is covered in some detail in the FM. Go thou, and
    > RTFM.


    Well, perhaps I should have stated my motivation. I'm running a mature
    app (very mature!). I need to consolidate to running on fewer
    MicroVAXes. My app starts a process for each trader. Each of these
    processes runs the same executable and it is not INTSTALed. I was
    concnerned that memory might get a little tight so I thought: Why not
    install it shared to save a little memory? I mentioned this to my
    developer (this occurred years ago) and he said we'd have to test
    every possible combination of posting prices and executing trades
    among multiple simultaneous users. I thought he was wrong but let it
    go. Now it's a little more urgent (but not immediate) so I thought I'd
    ask here to be certain. (Perhaps he was thinking of installing the way
    we install our shared memory files with INSTALL/SHARE/WRITABLE! Then I
    could understand his concern.)

    Now, if the answer is that it's okay to INSTALL any old image with /
    SHARE and private data won't get mixed among concurrent processes
    running the same image, then I can INSTALL/SHARE this image and I'm
    done. If the answer is: You have to write your app such and such a way
    to prevent private data corruption then I will not INSTALL/SHARE
    anything and I'm done. No one is going to rewrite this app for this.
    So I don't see any need to RTFM. I just wanted to know if anything
    special needs to be done when writing the program or any old program
    can safely be INSTALL/SHAREd without having to become an expert on
    programming when I'm not going to write or rewrite any code and
    haven't touched 3GL's since 1993 and then only writing FORTRAN
    programs to do physics calculations (no fancy stuff like global
    sections, shared this, shared that, privs, macro, etc.)

    AEF

  7. Re: Question about INSTALLing shared images

    On Dec 26, 2:29 pm, JF Mezei wrote:
    > AEF wrote:
    > > When you INSTALL an executable as a shared image, can it be any
    > > executable?

    >
    > No. You can't install a OS-X executable on VMS. :-)
    >
    > If your application is written in C, there are certain constructs with
    > public variables which may prevent it from being installed/shared if I
    > remember correctly. If I recall, the "extern" type of declaration is not
    > compatible with installing image/shared.


    Written in Pascal.

    >
    > (Or this could be a linker issue not allowing /SHARED to be used in such
    > circumstances).
    >
    > Similarly, your executable must be linked/NOTRACEBACK when it is
    > installed/shared.


    Really? What if it isn't? How does it fail or err?

    >
    > This is all from fairly distant memory with no parity bit.


    OK.

    AEF

  8. Re: Question about INSTALLing shared images

    AEF wrote:

    To answer your question, generally, the way VMS is setup, you won't have
    shared writeable sections between instances of the same shared images
    unless you're taken active steps to make it happen.

    The one area to be careful is externally defined variables. There are
    some which you can define as being writeable.

    You could write a small application that defines variables in every way
    that they were defined in your real application. Then the application
    prompts for an option to display those variables, and an option to set
    them to some value.

    One user runs the app and displays the values, while another user runs
    the app and sets the values. You should then be able to prove that n9one
    of the means to define variables in your production aopplication would
    result in shared data.



    >> Similarly, your executable must be linked/NOTRACEBACK when it is
    >> installed/shared.

    >
    > Really? What if it isn't? How does it fail or err?


    There is an error generated by link if there are incompatible options.

    Similarly, if install detects bad image attributes, it won't let you do
    the install/share. (I think it applies to traceback as well as /debug as
    well).



  9. Re: Question about INSTALLing shared images

    In article <47729ddb$0$4320$c3e8da3@news.astraweb.com>, JF Mezei
    writes:

    > AEF wrote:
    >
    > > When you INSTALL an executable as a shared image, can it be any
    > > executable?

    >
    > No. You can't install a OS-X executable on VMS. :-)


    Perhaps not, but you can install an Alpha image on Itanium and/or vice
    versa.


  10. Re: Question about INSTALLing shared images

    AEF wrote:
    > On Dec 26, 2:29 pm, JF Mezei wrote:
    >> AEF wrote:
    >>> When you INSTALL an executable as a shared image, can it be any
    >>> executable?

    >> No. You can't install a OS-X executable on VMS. :-)
    >>
    >> If your application is written in C, there are certain constructs with
    >> public variables which may prevent it from being installed/shared if I
    >> remember correctly. If I recall, the "extern" type of declaration is not
    >> compatible with installing image/shared.

    >
    > Written in Pascal.


    I'm not familiar with the implementation details for Pascal, but there
    are some issues with FORTRAN and C, so there may be some for Pascal as well.

    If I understand your intent, you want all read only data/code to be
    shared and all writable variables to be private. (The stack is always
    private.)

    By default FORTRAN COMMON blocks are shared writable as can be some C
    "extern" variables. IIRC, any PSECT with the "GBL" and "WRT" attributes
    is problematic.

    Fortunately, INSTALL will tell you if you have any such PSECTS, so you
    have some warning.

    Also fortunately, managing this does not require any code changes or
    special compiler switches. You can override the PSECT attributes with a
    linker options file.

    So as long as your image is not installed writable, I think you are OK.




    >> (Or this could be a linker issue not allowing /SHARED to be used in such
    >> circumstances).
    >>
    >> Similarly, your executable must be linked/NOTRACEBACK when it is
    >> installed/shared.

    >
    > Really? What if it isn't? How does it fail or err?
    >
    >> This is all from fairly distant memory with no parity bit.

    >
    > OK.
    >
    > AEF



    --
    -----------------------------------------------------------------------
    Chris Scheers, Applied Synergy, Inc.

    Voice: 817-237-3360 Internet: chris@applied-synergy.com
    Fax: 817-237-3074

  11. Re: Question about INSTALLing shared images

    On Dec 26, 10:19 am, AEF wrote:
    > Season's Greetings (I actually saw this in big letters hanging from
    > the ceiling of a Wegmans supermarket!)
    >
    > My apologies if this is a dumb question, but I want to be 100%
    > certain. (Hey, at least it's on topic!!!)
    >
    > When you INSTALL an executable as a shared image, can it be any
    > executable? I once discussed this with my developer for a program run
    > by multiple traders and he said we'd have to check for traders
    > stepping on each other, so to speak. So my question is: Doesn't VMS
    > automatically provide each process running shared executable its own
    > private data area in memory or does the program have to be explicitly
    > written with the assumption that it will be installed shared?
    >
    > Thanks
    >
    > AEF


    AEF,

    A key comment in your posting (and followup) is that this is a VAX
    executable.

    Some compilers on VAX flagged certain variables as shareable. This
    does no harm, so long as the image is not INSTALLed. It can produce
    [spectacular] failing results if this is the case. (While I have never
    fallen into this trap [I was aware of it from the PDP-11 days, and
    always thought it was a poor default then], I have had several clients
    fall into it.

    The cure is straightforward. A review of the LINK map, together with
    an appropriate LINK options file and a reLINK will quite happily
    resolve the problem.

    I cannot write any more at the moment, since I am in the middle of a
    client reconfiguration, and have to get back to preparing for
    tomorrow.

    - Bob Gezelter, http://www.rlgsc.com

  12. Re: Question about INSTALLing shared images

    AEF wrote:
    > On Dec 26, 11:33 am, "Richard B. Gilbert"
    > wrote:
    >> AEF wrote:
    >> My recollection is that the writeable areas are unique while the read
    >> only stuff (code, constants, etc.) is shared.

    >
    > Thanks!


    That is correct.

    >> ISTR that the subject is covered in some detail in the FM. Go thou, and
    >> RTFM.

    >
    > Well, perhaps I should have stated my motivation. I'm running a mature
    > app (very mature!). I need to consolidate to running on fewer
    > MicroVAXes. My app starts a process for each trader. Each of these
    > processes runs the same executable and it is not INTSTALed. I was
    > concnerned that memory might get a little tight so I thought: Why not
    > install it shared to save a little memory?


    In general, any executable that will be run by more than one person will
    probably benefit from being installed shared.

    Installed share/header_resident will reduce the amount of memory used by
    the process, and it will also speed up the image activation.

    There is a small memory penalty system wide for installing images. It
    is less than the amount of memory consumed by the second copy of the
    image running. Especially if it is commonly used.

    If you want candidates of images to be installed, then do the DCL
    command $show dev/files/nosystem on each of your disks.

    If you see any executables in there more than once, you will probably be
    better off installing them.

    Note that you may have to increase the sysgen parameters for global
    sections and pages.

    Other SYSGEN tuning including RMS parameters can also help.

    But the biggest gains can be from buying faster hardware of course.

    > I mentioned this to my
    > developer (this occurred years ago) and he said we'd have to test
    > every possible combination of posting prices and executing trades
    > among multiple simultaneous users. I thought he was wrong but let it
    > go. Now it's a little more urgent (but not immediate) so I thought I'd
    > ask here to be certain. (Perhaps he was thinking of installing the way
    > we install our shared memory files with INSTALL/SHARE/WRITABLE! Then I
    > could understand his concern.)


    A writable image requires special coding to link and the writable image
    can not be shared between nodes on a cluster. Older VMS versions did
    not enforce that restriction.

    > Now, if the answer is that it's okay to INSTALL any old image with /
    > SHARE and private data won't get mixed among concurrent processes
    > running the same image, then I can INSTALL/SHARE this image and I'm
    > done.


    That is pretty much it.

    > If the answer is: You have to write your app such and such a way
    > to prevent private data corruption then I will not INSTALL/SHARE
    > anything and I'm done. No one is going to rewrite this app for this.


    If the application has a linked in memory area that is shared between
    two processes, then it already needed to be installed for this to work.

    > So I don't see any need to RTFM. I just wanted to know if anything
    > special needs to be done when writing the program or any old program
    > can safely be INSTALL/SHAREd without having to become an expert on
    > programming when I'm not going to write or rewrite any code and
    > haven't touched 3GL's since 1993 and then only writing FORTRAN
    > programs to do physics calculations (no fancy stuff like global
    > sections, shared this, shared that, privs, macro, etc.)


    Privileged images must be linked /notrace to be installed.
    Non-privileged images do not need any special treatment.

    -John
    wb8tyw@qsl.network
    Personal Opinion Only

  13. Re: Question about INSTALLing shared images

    In article , AEF writes:
    >
    > When you INSTALL an executable as a shared image, can it be any
    > executable? I once discussed this with my developer for a program run
    > by multiple traders and he said we'd have to check for traders
    > stepping on each other, so to speak. So my question is: Doesn't VMS
    > automatically provide each process running shared executable its own
    > private data area in memory or does the program have to be explicitly
    > written with the assumption that it will be installed shared?


    Each image is broken up into program sections (PSECTs). PSECTs can
    be read only, writeable, shareable, ...

    You need to look at the LINK map and verify that you don't have any
    PSECTs that are both writeable and shareable. If that's true you
    can install /shared and you will use less physical RAM. If that's
    not then you can re-LINK the image using a linker options file to
    change the PSECT characteristics.

    The older Fortran compilers for VAXen made all the COMMON blocks
    shareable and writeable. Current Fortran compilers and other
    language compilers don't tend to do this. Many compilers have ways
    of specifying this in the source code, so you don't have to use
    linker options.


  14. Re: Question about INSTALLing shared images

    In article <9cWdnVXBQ-zjCe_anZ2dnUVZ_hKdnZ2d@comcast.com>, Bob Willard writes:
    >
    > If the multiple instances of an app write to a single shared file,
    > then the app needs to lock the shared file before and unlock it after
    > writing to that file; else, the copies may corrupt the file.


    If the app uses RMS (most on VMS do), and specifies that shared
    access is allowed, then RMS will provide the necessary locking.

    The app needs to be prepared to handle errors due to blocked access
    to a records that another copy has locked.


  15. Re: Question about INSTALLing shared images

    If you don't use the [OVERLAID] attribute in the Pascal source, then you
    are probably all set. Just compile, link, and install/SHARED/OPEN/HEADER

    --
    John Reagan
    OpenVMS Pascal/Macro-32/COBOL Project Leader
    Hewlett-Packard Company

  16. Re: Question about INSTALLing shared images

    On 2 Jan 2008 07:53:53 -0600, koehler@eisner.nospam.encompasserve.org (Bob
    Koehler) wrote:

    >In article , AEF writes:
    >>
    >> When you INSTALL an executable as a shared image, can it be any
    >> executable? I once discussed this with my developer for a program run
    >> by multiple traders and he said we'd have to check for traders
    >> stepping on each other, so to speak. So my question is: Doesn't VMS
    >> automatically provide each process running shared executable its own
    >> private data area in memory or does the program have to be explicitly
    >> written with the assumption that it will be installed shared?

    >
    > Each image is broken up into program sections (PSECTs). PSECTs can
    > be read only, writeable, shareable, ...
    >





    > You need to look at the LINK map


    I once installed an image with one psect incorrectly marked as SHR.
    Oops.

    Duane

    > and verify that you don't have any
    > PSECTs that are both writeable and shareable. If that's true you
    > can install /shared and you will use less physical RAM. If that's
    > not then you can re-LINK the image using a linker options file to
    > change the PSECT characteristics.
    >
    > The older Fortran compilers for VAXen made all the COMMON blocks
    > shareable and writeable. Current Fortran compilers and other
    > language compilers don't tend to do this. Many compilers have ways
    > of specifying this in the source code, so you don't have to use
    > linker options.



  17. Re: Question about INSTALLing shared images

    On Jan 2, 9:44 pm, D Gillbilly wrote:
    > On 2 Jan 2008 07:53:53 -0600, koeh...@eisner.nospam.encompasserve.org (Bob
    >
    > Koehler) wrote:
    > >In article , AEF writes:

    >
    > >> When you INSTALL an executable as a shared image, can it be any
    > >> executable? I once discussed this with my developer for a program run
    > >> by multiple traders and he said we'd have to check for traders
    > >> stepping on each other, so to speak. So my question is: Doesn't VMS
    > >> automatically provide each process running shared executable its own
    > >> private data area in memory or does the program have to be explicitly
    > >> written with the assumption that it will be installed shared?

    >
    > > Each image is broken up into program sections (PSECTs). PSECTs can
    > > be read only, writeable, shareable, ...

    >
    > > You need to look at the LINK map

    >
    > I once installed an image with one psect incorrectly marked as SHR.
    > Oops.
    >
    > Duane
    >
    > > and verify that you don't have any
    > > PSECTs that are both writeable and shareable. If that's true you
    > > can install /shared and you will use less physical RAM. If that's
    > > not then you can re-LINK the image using a linker options file to
    > > change the PSECT characteristics.

    >
    > > The older Fortran compilers for VAXen made all the COMMON blocks
    > > shareable and writeable. Current Fortran compilers and other
    > > language compilers don't tend to do this. Many compilers have ways
    > > of specifying this in the source code, so you don't have to use
    > > linker options.


    Thanks every one for your answers.

    It looks like I better abort. My developer isn't going to be assigned
    time for this at this time. Thanks again!

    AEF

  18. Re: Question about INSTALLing shared images

    AEF wrote:
    > On Jan 2, 9:44 pm, D Gillbilly wrote:
    >
    >>On 2 Jan 2008 07:53:53 -0600, koeh...@eisner.nospam.encompasserve.org (Bob
    >>
    >>Koehler) wrote:
    >>
    >>>In article , AEF writes:

    >>
    >>>>When you INSTALL an executable as a shared image, can it be any
    >>>>executable? I once discussed this with my developer for a program run
    >>>>by multiple traders and he said we'd have to check for traders
    >>>>stepping on each other, so to speak. So my question is: Doesn't VMS
    >>>>automatically provide each process running shared executable its own
    >>>>private data area in memory or does the program have to be explicitly
    >>>>written with the assumption that it will be installed shared?

    >>
    >>> Each image is broken up into program sections (PSECTs). PSECTs can
    >>> be read only, writeable, shareable, ...

    >>
    >>> You need to look at the LINK map

    >>
    >> I once installed an image with one psect incorrectly marked as SHR.
    >> Oops.
    >>
    >> Duane
    >>
    >>
    >>> and verify that you don't have any
    >>> PSECTs that are both writeable and shareable. If that's true you
    >>> can install /shared and you will use less physical RAM. If that's
    >>> not then you can re-LINK the image using a linker options file to
    >>> change the PSECT characteristics.

    >>
    >>> The older Fortran compilers for VAXen made all the COMMON blocks
    >>> shareable and writeable. Current Fortran compilers and other
    >>> language compilers don't tend to do this. Many compilers have ways
    >>> of specifying this in the source code, so you don't have to use
    >>> linker options.

    >
    >
    > Thanks every one for your answers.
    >
    > It looks like I better abort. My developer isn't going to be assigned
    > time for this at this time. Thanks again!
    >
    > AEF


    Abort? I think the odds are about 99.9999% that it would be fine.

    If you "install add/share/header/open" and then do "install list/global"
    on the image, you will see whether or not there are any writable
    shared sections. (Writable non-shared sections will be copy-on-
    reference.) If there are none, then you're fine.

    If you want to test a particular image before installing it, copy it
    to a test directory under a different name, install the copy, and check.

    If okay, then uninstall and delete the copy, and install the original.

    If not okay, uninstall and delete the copy, and add it to your list of
    things to fix someday.


    --
    John Santos
    Evans Griffiths & Hart, Inc.
    781-861-0670 ext 539

  19. Re: Question about INSTALLing shared images

    On Jan 3, 6:33 pm, John Santos wrote:
    > AEF wrote:
    > > On Jan 2, 9:44 pm, D Gillbilly wrote:

    >
    > >>On 2 Jan 2008 07:53:53 -0600, koeh...@eisner.nospam.encompasserve.org (Bob

    >
    > >>Koehler) wrote:

    >
    > >>>In article , AEF writes:

    >
    > >>>>When you INSTALL an executable as a shared image, can it be any
    > >>>>executable? I once discussed this with my developer for a program run
    > >>>>by multiple traders and he said we'd have to check for traders
    > >>>>stepping on each other, so to speak. So my question is: Doesn't VMS
    > >>>>automatically provide each process running shared executable its own
    > >>>>private data area in memory or does the program have to be explicitly
    > >>>>written with the assumption that it will be installed shared?

    >
    > >>> Each image is broken up into program sections (PSECTs). PSECTs can
    > >>> be read only, writeable, shareable, ...

    >
    > >>> You need to look at the LINK map

    >
    > >> I once installed an image with one psect incorrectly marked as SHR.
    > >> Oops.

    >
    > >> Duane

    >
    > >>> and verify that you don't have any
    > >>> PSECTs that are both writeable and shareable. If that's true you
    > >>> can install /shared and you will use less physical RAM. If that's
    > >>> not then you can re-LINK the image using a linker options file to
    > >>> change the PSECT characteristics.

    >
    > >>> The older Fortran compilers for VAXen made all the COMMON blocks
    > >>> shareable and writeable. Current Fortran compilers and other
    > >>> language compilers don't tend to do this. Many compilers have ways
    > >>> of specifying this in the source code, so you don't have to use
    > >>> linker options.

    >
    > > Thanks every one for your answers.

    >
    > > It looks like I better abort. My developer isn't going to be assigned
    > > time for this at this time. Thanks again!

    >
    > > AEF

    >
    > Abort? I think the odds are about 99.9999% that it would be fine.
    >
    > If you "install add/share/header/open" and then do "install list/global"
    > on the image, you will see whether or not there are any writable
    > shared sections. (Writable non-shared sections will be copy-on-
    > reference.) If there are none, then you're fine.
    >
    > If you want to test a particular image before installing it, copy it
    > to a test directory under a different name, install the copy, and check.
    >
    > If okay, then uninstall and delete the copy, and install the original.
    >
    > If not okay, uninstall and delete the copy, and add it to your list of
    > things to fix someday.
    >
    > --
    > John Santos
    > Evans Griffiths & Hart, Inc.
    > 781-861-0670 ext 539


    OK, here are the results as run on my test system:

    INSTALL> ADD FTEXE:FTTRDSTN /SHARE/HEAD/OPEN
    INSTALL> LIST FTEXE:FTTRDSTN

    DISK$DATA1:.EXE
    FTTRDSTN;387 Open Hdr Shar
    INSTALL> LIST FTEXE:FTTRDSTN/GLOB

    DISK$DATA1:.EXE
    FTTRDSTN;387 Open Hdr Shar

    System Global Sections

    DSA1:FTTRDSTN.EXE
    INS$87709BE0_001(0273CFCD) PRM SYS Pagcnt/
    Refcnt=504/0

    So is this okay? If I run the same command on our main shared-
    memory .exe file I get this:

    INSTALL> LIST LIB:FTSHRMEM/GLOB

    DISK$OPENVMS062:.EXE
    FTSHRMEM;1 Open Shar Lnkbl
    Wrt

    System Global Sections

    DSA0:FTSHRMEM.EXE
    INS$87709160_002(02639233) WRT PRM SYS Pagcnt/
    Refcnt=1/0
    INS$87709160_001(02639233) WRT PRM SYS Pagcnt/
    Refcnt=9943/0

    INSTALL>

    I see an additional item: WRT. But this one is already installed
    shareable and writable for inter-process communication, not to save
    pages in memory.

    AEF

  20. Re: Question about INSTALLing shared images

    In article <9ffac91c-c1fb-4798-817c-cfb167017511@p69g2000hsa.googlegroups.com>, AEF writes:
    >
    > INSTALL> ADD FTEXE:FTTRDSTN /SHARE/HEAD/OPEN
    > INSTALL> LIST FTEXE:FTTRDSTN
    >
    > DISK$DATA1:.EXE
    > FTTRDSTN;387 Open Hdr Shar
    > INSTALL> LIST FTEXE:FTTRDSTN/GLOB
    >
    > DISK$DATA1:.EXE
    > FTTRDSTN;387 Open Hdr Shar
    >
    > System Global Sections
    >
    > DSA1:FTTRDSTN.EXE
    > INS$87709BE0_001(0273CFCD) PRM SYS Pagcnt/
    > Refcnt=504/0
    >
    > So is this okay? If I run the same command on our main shared-
    > memory .exe file I get this:
    >
    > INSTALL> LIST LIB:FTSHRMEM/GLOB
    >
    > DISK$OPENVMS062:.EXE
    > FTSHRMEM;1 Open Shar Lnkbl
    > Wrt
    >
    > System Global Sections
    >
    > DSA0:FTSHRMEM.EXE
    > INS$87709160_002(02639233) WRT PRM SYS Pagcnt/
    > Refcnt=1/0
    > INS$87709160_001(02639233) WRT PRM SYS Pagcnt/
    > Refcnt=9943/0
    >
    > INSTALL>
    >
    > I see an additional item: WRT. But this one is already installed
    > shareable and writable for inter-process communication, not to save
    > pages in memory.
    >


    OK, so the file that is supposed to contain writeable shareable
    sections does, and the file that isn't doesn't. I'd set it up, run
    some tests, and plan for success. But don't forget options to fix
    any problems if all of us together missed something.


+ Reply to Thread
Page 1 of 2 1 2 LastLast