× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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  / \
--------------------------------------------------------------------



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.