Re: Re: Commands to joblog -- MI400

Wow!

I used to think that I was pretty sharp on the AS/400 (and the S/38 before 
that, and the S/3
before that).  I used to think that I could do anything... well, almost... 
certainly a lot more
than most nine-to-fivers that just want to write the report the boss needs so 
they can go
home.  I used to think my contribution was pretty awesome.  Maybe that's all 
because ... I
used to think.  :)

You guys are AWESOME!  Thanks, Dave and Simon and the others for reminding me of
what I so love about my job!  And for a gentle reminder of the cost of sitting 
back on one's
laurels (what's a laurel?) and enjoying the "awesome" status that may well be a 
figment of
one's own imagination!  :)

Yeah, I'm still comfortable with my knowledge of the systems and thankful for a 
wonderful
mind for things technical.  Now if I can just get back home to my iSeries 
system and do
some real playing.  But first, there's this report that the boss needs to have 
by 5:00.....
--
Qiu Min & Dennis Lovelady
mail: dennis@lovelady.com
URL:  http://www.lovelady.com
ICQ:  5734860
--
"Because of our taping schedule, this show will take place three weeks after 
you see it."
  -- sportscaster Don Gillis


On 19 Jan 2002 at 7:28, Dave McKenzie wrote:

> 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
> _______________________________________________
> 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.
>