× 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 Dave,

I want to know more . . .

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 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)?

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

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

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

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

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 :)

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-Ups:

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.