Re: [MI400] MATHSAT and MATRMD broken?

["Diane Hellie" <hellie@xxxxxxxxxx>]

Can you please provide additional information on which MATRMD include field
you needed to change to packed?

Diane Hellie
  MI Architecture Owner
  DGZA/030-2T910 (Apple Ridge Blvd)
  253-7742




                      "Simon Coulter"
                      <shc@flybynight.c        To:       mi400@midrange.com
                      om.au>                   cc:
                      Sent by:                 Subject:  [MI400] MATHSAT and 
MATRMD broken?
                      mi400-admin@midra
                      nge.com


                      02/11/02 07:05 AM
                      Please respond to
                      mi400






Hello All,

I'm not sure you can help me with this but there is no point talking to
IBM support on this.  No one locally will understand what I'm doing and
since it is on 440 I can't get official support.

Problem 1
=========
In an effort to track what is happening on the heap, and because I
couldn't find any other way to solve this, I used the MATHSAT (Materialize
Heap Space Attributes) instruction to see what's happening on the heap.
The MI Reference shows this instruction as returning counts of the number
of allocations, reallocations, and deallocations occuring on the specified
heap.  The default heap has a heap ID of 0 and as far as I can tell the
default heap is used by the C functions malloc(), realloc(), and free().
Each activation group has its own heap (or possibly more than one).  The
default heap is created on the first use of malloc() or CEEGTST.

Here is the MI code:

    DCL SPCPTR @HEAP_INFO PARM;
      DCL DD HEAP_INFO BAS(@HEAP_INFO) CHAR(1000);
        DCL DD BYTES_PROV  DEF(HEAP_INFO) POS(1) BIN(4);
        DCL DD BYTES_AVAIL DEF(HEAP_INFO) POS(5) BIN(4);
    DCL SPCPTR @HEAP_ID PARM;
      DCL DD  HEAP_ID BAS(@HEAP_ID) CHAR(8);
        DCL DD ACT_GRP DEF(HEAP_ID) POS(1) BIN(4) UNSGND;
        DCL DD HEAP    DEF(HEAP_ID) POS(5) BIN(4) UNSGND;
    DCL OL ENTRY ( @HEAP_INFO, @HEAP_ID ) EXT PARM MIN(2);

    DCL CON HEAP_SPACE_ATTR CHAR(1) INIT(X'00');

 ENTRY * (ENTRY) EXT;

 BRK '0001';
    MATHSAT  @HEAP_INFO, @HEAP_ID, HEAP_SPACE_ATTR;

 BRK '0002';
    DEACTPG *;
    RTX *;
    PEND;

This is invoked from a C program that determines the activation group mark
(via MATAGPAT) and sets the heap ID to 0.  This is necessary to avoid
issues due to the OPM MI program running in the default activation group
but the program that allocates the heap storage is in a *NEW activation
group.  (I would prefer to do it all via C but IBM did not provide an
include for MATHSAT and the C compiler barfs with an invalid instruction
stream when I created one -- I think it objects to the _MATHSAT built-in
but that's a subject for another note.) I have a C structure that corectly
maps the heap space attributes according to the documentation in the 440
MI reference manual.  The address of this structure is passed as the first
parameter to the above MI program.

The C program also allocates storage from the default heap using both
malloc() and the CEEGTSTG API, it reallocates that storage using both
realloc() and CEECZST, and releases the storage using both free() and
CEEFRST.  There is one call to each function and I use separate pointers
for each class of function (i.e., one pointer for alloc(), realloc() and
free(), and another pointer for the CEE APIs).

Then it invokes the above MI program.  The program works (as in no
exceptions) however the counts of allocations, reallocations and
deallocations are not set correctly.  They are all zero with the exception
of the reallocation count which is 1.  Using debug I determined this is
set as a result of calling the CEECZST API.  CEEGTST, CEEFRST, alloc(),
realloc(), and free() have no effect on the counts.  The other fields in
the structure (e.g., allocation strategy bits) are set correctly. I've
looked at the raw data in hex in case the problem was due to misalignment
but the count fields are definitely zero.  Strange?  Broken?

Problem 2
=========
Since MATHSAT did not work as documented I tried the MATRMD instruction.
Option X'17' of this instruction returns storage allocation values for
every thread and task on the system.  The code is in C but is using the MI
built-in _MATRMD.  The include for MATRMD has an error and one of the
structures should be _Packed but is not thus the structure is thrown out
by padding bytes.  I fixed that :)

I retrieve the PCS pointer and materialize it to get the PCS name.  I use
this value to search the list of tasks and I print out the allocation
amount, deallocation amount, and the difference between them.  These
values are in pages rather than bytes.  So I use option X'12' of MATRMD to
get the page size in bytes.  Here is the problem.  I provide 64 bytes of
space for the materialization which is enough for the the control
information which includes the page size.  Most of the other fields in the
structre are set correctly (number of ASPs, number of disk units, etc.)
but the page size is ZERO!!  What use is that when the allocation values
returned by many of the MI functions are in pages.  How can you convert
from pages to bytes except by hardcoding a page size (IIRC it is 4096)
which is not nice.  Why is this value zero?

Questions
=========
Am I mad?  Should these instructions work as I expect?  Has anyone else
tried using these MI instructions?  Did they work for you?  These programs
are user-state because nothing in the documentation suggests that they
require system-state access.  I might try that to see if it helps.

I can supply the additional C code for those of you interested in
investigating this.

Regards,
Simon Coulter.

--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------

_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/mi400
or email: MI400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.