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