Conference vaxaxp::vmsnotes

    re .0   
    
    Small but complete demonstration program?
    
    Is he trying to _map_ a global section or _create_ a global section?
    
    What is the meaning of "becomes installed"? Is the INSTALL command
    somehow relevant here?
    
    What on earth does he mean by "two separate pieces"? How can he tell?
    Does the retadr argument come back with the expected values, in
    particular the expected difference between the first longword and the
    second?
    
    What kind of global section (probably need at least to see what SEC
    flags)?
    
    What database product? I assume we are talking about some home-brew
    database that he has written and which uses global sections to get data
    out of a database file.

>>         <<< Note 558.1 by AUSS::GARSON "DECcharity Program Office" >>>
>>                        -< all questions - no answers >-

>>    Small but complete demonstration program?

Try the following.
$create big_global.for
	program main
	structure /page/
	byte	lines(512)
	end structure
	record /page/big_global(70000)
	common /big_global/big_global
	end
$fortran big_global
$link/share big_global
$install add/open/write/share mydisk:[mydir]big_global
$install list/global

According to my customer, installing this single image results in
two global sections being created.  One named big_image_001 with
a size of 65535, and the other named big_image_002 with a size of
<70000-65536>.
    
>>    Is he trying to _map_ a global section or _create_ a global section?

Yes.  After installing the large common, he runs a program that
calls $mgblsc to map various pieces of it.  When he attempts to
map beyond page 65535 of the _001 section, he fails with a
ss$_endoffile error.

Now that I better understand the problem, I see that this is because
he has created two separate sections.  To map beyond page 65535, he
needs to map the second section.
    
>>    What is the meaning of "becomes installed"? Is the INSTALL command
>>    somehow relevant here?

Yes.  See above.
    
>>    What on earth does he mean by "two separate pieces"? How can he tell?
>>    Does the retadr argument come back with the expected values, in
>>    particular the expected difference between the first longword and the
>>    second?

Actually, he's getting two separate global sections created when he
installed a shareable image with a common block (psect) greater
than 64k.
    
>>    What kind of global section (probably need at least to see what SEC
>>    flags)?

sec$m_gbl and sec$m_wrt.
    
>>    What database product? I assume we are talking about some home-brew
>>    database that he has written and which uses global sections to get data
>>    out of a database file.

No real database product.  Just his own, home-brewed mappping of an
installed common.

I apologize for the poor initial problem statement.  I knew better, but
I was having problems getting a decent explanation from the customer.
When I talked to him today, one of his co-workers was able to provide
a better explanation.

I will probably suggest he abandon the installed common because he will
run into problems with the names of the global sections when he upgrades
to v6.2.  I will suggest he use $crmpsc to create the initial section,
and then use the same logic for mapping and remapping.  I do have
two questions, though.

1) If you use $crmpsc to create a >64k section, will it create just one
section, or will it create a single, large section, or will it break it
into  2 or more sections?  And

2) Is there any way to install this large common so that it doesn't get split
into two separate sections?  This is the solution that my customer prefers,
even though it's probably not the best.

I would try this out for myself, but I can't find a system that has
enough free global pages.

thanks,

Jerry

    It seems to have been split by the linker.  Here's a piece of the .MAP
    from /MAP/FULL,
    
   Cluster      Type Pglts   Base Addr  Disk VBN PFC Protection and Paging      Global Sec. Name   Match     Majorid   Minorid
   -------      ---- -----   ---------  -------- --- ---------------------      ----------------   -----     -------   -------

DEFAULT_CLUSTER    2     1    00000000-R        3   0 READ WRITE   NON-SHAREABLE ADDRESS DATA
                   3     1    00010000-R        4   0 READ ONLY    EXECUTABLE
                   2 65536    00020000-R        0   0 READ WRITE   DEMAND ZERO
                   2  4464    02020000-R        0   0 READ WRITE   DEMAND ZERO
                   2     1    02250000-R        5   0 READ WRITE   FIXUP VECTORS

   Get rid of the COMMON, and use global sections directly.

   (Please see my previous "rants" about COMMONs in this and in other
   conferences for details on my opinion of COMMONS -- this is just
   one way the use of a COMMON can get one in trouble.  They're good
   for traditional Fortran shared memory access, but Fortran and many
   other languages have pointer support, and all can make full use of
   OpenVMS global sections...)

   Combining access to a COMMON from $crmpsc or other system services
   is not supported, and is not recommended, and -- as you appear to
   be aware -- will break in OpenVMS V6.2 and later.  (See 1748.* in
   NOTED::HACKERS for details.)

   As for global sections, one should code "relative section numbers",
   as this is how one can (easily) expand the size of the shared memory
   over time.  When one section is exhausted, one maps the next, and
   sets the linkages to indicate the next "record" is located in the
   next global section.

    re .2
    
    John's right. It seems to be a LINKer feature. My VAX doesn't have high
    enough VIRTUALPAGECNT even to link the program )-: but fortunately (?)
    the same problem occurs on Alpha. I would think this is QAR worthy.
    
    Like you I don't have sufficient GBLPAGES to verify that one can create
    a single global section > 65536 pagelets.
    
    If the customer insists on persevering with COMMON then he must abandon
    trying to map the global section created by the INSTALL command i.e.
    not try and second guess this arcane corner of VMS. This approach has
    always been bogus and will break further in V6.2.
    
    The customer should simply link against the shareable image and let the
    image activator handle the global section mapping. This should fix the
    problem that the customer is encountering under V6.1 and even allow the
    application to continue to work under V6.2. [Actually, I can't swear
    that this will fix the problem (I didn't test it) but if it doesn't,
    the customer at least has a leg to stand on when reporting the problem
    to Digital.]
    
    Or, as Steve says, the customer can abandon using a shareable image for
    this purpose and simply create and map the section explicitly.
    
    MHO is that using INSTALL /WRITE for sharing writeable data is a bit
    hacky and that explicitly managing the section is likely to work better
    in the long run.

    Yea, my example in .3 was on an Alpha.  I just tried it on my VAX
    (and after waiting a while listening to my paging disk rattle for 3.5
    minutes), it finally linked.  Here's the corresponding snipet from the 
    .MAP file on the VAX.
    
                                             +------------------------+
                                             ! Image Section Synopsis !
                                             +------------------------+

   Cluster      Type Pages   Base Addr  Disk VBN PFC Protection and Paging      Global Sec. Name   Match     Majorid   Minorid
   -------      ---- -----   ---------  -------- --- ---------------------      ----------------   -----     -------   -------

DEFAULT_CLUSTER    3 65535    00000000-R        2   0 READ WRITE
                   3  4465    01FFFE00-R    65537   0 READ WRITE
                   3     1    0222E000-R    70002   0 READ ONLY

    
    Interesting that with the Alpha linker, the 2 sections were
    65536 and 4464 Pglts in size while they are 65535 and 4465 pages
    on the VAX.  Oddly similar and yet oddly different.  Certainly worth
    a QAR.
    
    				-Joh

Well, I wouldn't expect the Alpha linker to break them at a non-8K boundary!

    On VAX, the ISDs appear to be limited to 65535 pages
    
    LIB.REQ:
      macro ISD_W_PAGCNT = 2,0,16,0 %;        ! ! OF PAGES DESCRIBED BY THIS ISD
    
    so I don't see how you get one larger than 65535 pages.
    
    
    BTW, on Alpha, the ISDs are different and don't appear to have the same
    limitation.
    
    LIB.REQ:
      macro EISD$L_SECSIZE = 12,0,32,0 %;     ! SIZE OF SECTION IN BYTES 
    					      ! DESCRIBED BY THIS ISD
    
    I'd like to know the rationale (if any) behind the breaking apart
    of the image sections on Alpha.  It just may be that the somewhat
    common code base of the linker just makes it happen on the Alpha
    by default since it has to for the VAX.
    
    				-John