I'm going to compress the messages thus far and attempt to explain the
differences. Please be
gentle; I am a first time poster here:
 
: > Chris Bartram wrote:
: >
: > >:listf sl.pub.sys,2
: > >ACCOUNT=  SYS         GROUP=  PUB
: >
: > >FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
: > >                  SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX
: > >
: > >SL      * SL      128W  FB       12080      12186   1    12192 34  *
: >
: On Fri, 15 Dec 1995, MR JOHN P BURKE wrote:
: >
: >  SL      * SL      128W  FB       91203     320000   1    92160 48  *
 
Don Harrington ([log in to unmask]) wrote:
 
:    SL      * SL      128W  FB      111596     320000   1   112640 58  *
 
: so I'm curious what the problem is, too  :-)
 
So am I, but for different reasons. Here's an explanation based on the school
of hard knocks
learning and no formal training; it is more my opinion based on experience than
anything. Now,
Chris's SL looks like something from a V/E system; however, it could just have
easily been
that way on an MPE/iX system. How?  By using the Segmenter and performing a
CLEANSL or COPYSL
command against the existing translated SL in an attempt to clean out the
fragmented space in
the file or increase the internal size of the file - from a Segmenter point of
view, not a
File System point of view.
 
What do I mean by a "translated SL"? This is an SL that has been modified by
our OCT tool,
Optimizing Compiler Translator. For those of you familiar with migration from
V/E to /iX,
you know this translator takes an existing V/E program and converts the
Compatibility Mode
(CM) instructions to Native Mode (NM) instructions and appends those NM
instructions to the
CM program. This activity increases the size of the original CM file by about a
factor of 10
(more or less depending on how many NM instructions it takes to translate a
single CM
instruction). There is a tool called OCTUTIL in the MPEXL.TELESUP group on any
system (except
for those of you who like to remove TELESUP) that can show you whether a file
is translated
or not - SL included; it has a minimal help facility. I said earlier that
Chris's SL doesn't
look like it has been translated. Now look at Don's and John's SLs; these are
definately
translated because 1) the EOF size is so large, 2) the LIMIT is even larger.
John's has less
products/third party products in his SL than does Don. As an aside, before
Release 4.0, the
LIMIT used to be set at 4096000 by OCT, but it was changed to 320000 for some
reason.
 
Now, when we translate SL in the factory, we use special options for maximum
performance
against certain OS segments. We carry those special options with us when we
patch or add new
segments to your SL. If you run into the problem Chris originally described,
this usually means
your CM portion of the file is either too fragmented or too full to replace
existing CM segments
or add new CM segments. The only way to correct this is to use the Segmenter
CLEANSL or COPYSL
commands, but that removes the translation (read "performance gain") we
originally delivered to
you in (literally) a few seconds. It takes 30-90 minutes for OCT to put that
translation back
again depending on the size of the file, system performance, etc. It also
doesn't replace
previously translated code, it just keeps appending new copies to the file. So
you can see your
SL EOF grow quite a bit with a couple of PowerPatch applications, but you
shouldn't be affected
unless you translate so much you hit the LIMIT of 320000 records. In Chris's
case, you're
caught between a rock and a hard place. Not only that, we are pretty close to
maxing out the
file space for the CM portion of the file already. So, you can only get
two-five 5% increases
before you can no longer physically expand the CM portion of the file.
 
You can throw the tomatoes at me now as I developed the ugly AUTOPAT scripts
the RC delivers to
you that will allow you to retranslate a CLEANSLed/COPYSLed SL properly so you
get maximum
performance.  Most customers don't hit this problem very often, but it's easy
to hit if you
have most of our products, third party products that add segments (run out of
space) or lots of
patches (fragmented space). Unfortunately, our tools were not designed at all
to handle this
situation and to detect the condition, expand the CM file, retranslate, etc
would be a
monumental task to undertake and perform correctly given the existing toolset.
I hope this
helps your understanding of the situation and gives you some insight as to
why/how this happens.
 
 
Mike
 
PS My curiosity stems only from what Chris has on his system and what the
history is of adding or
replacing segments in SL so I can better understand the causes beyond what I
have descibed above.
         __
        / /
       / /                   Mike Hess - MPE/iX Escalation/System Release Mgmt
      / /____    _______          Mail   19447 Pruneridge Ave.  M/S 44UA
     / ___  /   / ___  /                 Cupertino, CA  95014
    / /  / /   / /  / /          Phone   Telnet / (408) 447-1311
   / /  / /   / /__/ /
  /_/  /_/   / _____/           HPDesk   Mike HESS / HP4700/M2
            / /                 E-mail   [log in to unmask]
           / /                  Fax      Telnet / (408) 447-4278
          /_/
 
   "My desk has a lot in common with my e-mail address."