Re: MATHSAT and MATRMD broken?

what? fixing the problem by changing the manual?

----- Original Message -----
From: Diane Hellie <hellie@us.ibm.com>
To: <mi400@midrange.com>
Sent: Monday, February 11, 2002 10:53 AM
Subject: Re: [MI400] MATHSAT and MATRMD broken?


>
> The MATHSAT instruction does not return allocation information if operand 3
> is hex 02 and the heap is a default heap.
>
> The following information will be added to the MI architecture in a future
> release:
>
> If operand 3 is equal to hex 02 AND the heap being used is a default
> heap, then not all the allocation information is available.
> Specifically, the following fields in the template will always be
> zero:
>
> --Current number of outstanding allocations
> --Total number of frees
> --Total number of allocations
> --Maximum number of outstanding allocations
>
>
> Diane Hellie
>
>
>
>
>
>                       "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.