Re: Re: Commands to joblog -- MI400

On Friday 18 January 2002 04:36 pm, Simon Coulter wrote:
> Hello Dave,
>
> I want to know more . . .

See interspersed comments below.

>
> I was playing with this yesterday as a result of Dennis' question.  I used
> TRCJOB to determine that QCADRV calls QMHSNDPM to send the command
> messages.  I used SST to determine that QMHSNDPM changes the external
> message types (e.g., *ESCAPE) to internal forms (e.g., ESCP) and that
> QMHSNDPM would support a CMD message (but not *CMD).  I also determined
> that CMD messages must be impromptu messages (verified by CPF24C4).
>
> I set a breakpoint in QMHSNDPM at '/0001' and then started DMPJOB for
> QMHSNDPM and QCADRV.  From the contents of program storage (see below) I
> could see that QCADRV uses PREV for the message queue, * for the call stack
> entry, and CMD for the message type but I could not find the message text.
> After reading your code I can see some of the other values (which I have
> underlined).
>
> 00000C5A 00500000 00000000 00000000   <== Junk ???
> 80000000 00000000 D1D80C68 CD001630   <== Pointer to something (msg text)
> 80000000 00000000 DB2E5DF1 EC001000   <== Pointer to something ~~~~~~~~~~
> 004ED7E6 00000000 00000000 00000000   <== Junk ???
> 00000000 00000000 00000000 00000000
> 00000000 00000000 00000000 00000000
> D7D9C5E5 5C404040 40404040 404016F9   PREV*
> 00000000 00000000 00000000 00000000
> 20000000 00000000 0BC3D4C4 405DFF40                  CMD
>                              ~~~~
> F1F1F1F1 F1F1F1F1 F1F1F1F1 F1F1F1F1   <== Junk from here on?
> F1F1F1F1 F1F1F1F1 F1F1F1F1 F1F1F1F1
> F1F1F1F1 F1F10001 FFFFFFFF F1F1F1F1
>              ~~~~ ~~~~~~~~
> F1F1F1F1 F1F1F1F1 F1F1F1F1 F1F1F1F1
> F0F0F0F0 F0F0F0F0 F0F0F0F0 F0F0F0F0
> F0F0F0F0 F0F0F0F0 F0F0F0F0 F0F0F0F0
> F0F0F0F0 F0F0F0F0 F0F0F0F0 F0F0F0F0
> (and lots more of these char 1's and 0's)
>
> I was expecting QCADRV to obey the documented QMHSNDPM interface and tried
> many variations of:
>
>       CALL PGM(QMHSNDPM) PARM('       ' '                    ' +
>               '  300 - A TRACED LINE' X'00000016' 'CMD       ' +
>               '*         ' 'PREV' '     ' X'0000000000000000')
>
> and of course received the expected error messages about CMD not a valid
> message type and problems with PREV (for which I also tried X'00000001').
> I thought it might be that command messages must be sent from QCADRV and so
> created my own program called that (owned by QSYS and system state) but
> that didn't work (and wouldn't really be much use if it had worked).  I
> tried a number of other things too but they all proved fruitless.
>
> What made you twig to the single parameter interface?

I guess "twig" is Aussie for "grok?" :-)  Well, I cheated.  I had an old
defunct MI pgm lying around, dated 1994, which sent a scope msg using the
1-parm interface.  I can't remember '94 too well (can't even remember what I
had for dinner last night), but I think I found it by examining the
disassembled machine code of some QSYS pgm that calls QMHSNDPM (this was on
CISC).  I do recall seeing the code in QMHSNDPM that determines whether its
caller is system state by looking at a bit in the ICB.

> I would expect a
> single parameter to be contiguous storage but the dump above shows much
> junk between the parameters (nulls, 1's, and 0's).  I see that your
> structure has gaps which correspond to the 'junk' so it is contiguous and
> maps perfectly to the dump shown above.  What made you ignore all the nulls
> and character 1's and 0's among the real values (other than they just look
> wierd)?

I think the space between the significant stuff is other fields that aren't
used in this instance.  For example, when sending a scope msg, there's a
pointer to a 4-byte msg key at offset x'40'.  I'm guessing the 'junk' is
un-initialized storage.  I just used my trusty Occam's razor: started with
all hex 0's, adding the fields that were obviously needed and quit when it
worked.  (That and the QSYS pgm setting only those fields.)  I guess this is
the exact reverse of Michaelangelo's technique--starting with a marble block
and removing anything that doesn't look like a statue.

>
> What made you realise a pointer to the message text was passed?  (I should
> have followed those pointers ...)

I followed those pointers :-) til I found something that looked like a cmd
string.

>
> Why did you call the X'5DFF' value SPMSGID when it's not a valid message ID
> and is only 2-bytes long?

I changed it to x'0000' and got CPF2499 "Message identifer xxxxxxx not
allowed" where xxxxxxx is a very attractive reverse-image rectangle.
However, I couldn't find any CPF5DFF or MCH5DFF, or even 93xx in QCPFMSG.

>
> How did you know the X'0001' value was a parameter value when the field
> name SPB7 indicates its purpose is unknown?

I changed it to x'0000' and it worked fine, but the '94 pgm had x'0001' so I
left it.  The QSYS pgm passed x'0001' but I don't know what it is.

>
> How did you know the two X'FFFF' fields are CSSID and INVocation OFfset?
> (Although offset doesn't make much sense since the relative invocation
> entry is PREV in my dump and SAME in your code.)  Both of which are
> probably BIN(2) rather than CHAR(2).

Changing the CCSID field to x'0000' gets CPF247E "CCSID -1610612736 is not
valid."  But how they got -1610612736 (x'A0000000') out of x'0000' I don't
know.

Changing SPINVOF to x'ABCD' gets MCH4426 "Invocation offset outside range of
current stack."

>
> I, and probably others, would find a description of your investigative
> process helpful.  I guess the part I'm missing is how you determined the
> structure of the single parameter because the field names you use make it
> obvious that you know what most of them are for yet the data itself only
> helps with determining the purpose of three fields -- please don't tell me
> you just looked at the CPF microfiche, or used the CPF Data Areas manual :)

No, as Linus would say, "Microfiche?  We don't need no steenking Microfiche!!"

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

--Dave