Re: Parameter issues using QMHSNDPM API

What I wanted to do was post a message to QSYSOPR indicating the name of a
retrieved file. I tried SNDMSG and, while that worked, I would have preferred
a single line message like is produced by SNDPGMMSG. Earlier Rob suggested I
created a command and CL to accomplish this. As an experiment, I wrote a CL
that contains SNDPGMMSG. Calling that from a QSH session kind of worked. Initial test left garbage characters following my test message. So, I modified
the CL to move the message charcters from the incoming parameter to the variable
that was used in SNDPGMMSG, stopping on end of field, or a special delimiter. Odd, that does not produce an error in the QSH environment. Also does not
produce a message, either.

The reason for this futility is people ask, after the fact, whether so-and-so
got done. I just wanted to be able to answer that it had retrieved
such-amd-such file and move on. While SNDMSG works, SNDPGMMSG would look a
little nicer. A little more like other message that are there.

I think I have wasted enough people's time on this list with this.

John McKee

Quoting Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>:

John,

Even if everything worked the way you expected (which it won't) your
code makes no sense. Sending an *ESCAPE message to the system
operator's message queue? In what world does that make sense? The
system operator isn't a program, it can't deal with an *ESCAPE message.

But that's just a start:

a) The way you handled quoting is going to wreak havoc. Please re-read
the recent message about quoting in shell scripts that I wrote to Rob
Berendt on this list.

b) QMHSNDPM is for program messages, and the system operator's message
queue is not a program queue. That's why the API docs for QMHSNDPM don't
list *SYSOPR as an option... you can't send a program message to
*SYSOPR. There's a different API (QMHSNDM) that's for sending
non-program messages if that's what you want. (But they can't be type
*ESCAPE!)

c) The API docs for QMHSNDPM ask for binary(4) parameters for the
message length and the call stack count parameters. You are not passing
binary(4), however, you are passing a text string.

d) The final parameter to the API is an error code parameter, which is a
data structure made up of two binary(4) fields followed by optional text
fields. You are simply passing one blank for this parameter, instead of
passing what it asks for.

e) Sending a program message from QShell makes no sense whatsoever.
Remember, Unix does not use the same call-stack semantics as a
traditional IBM i program would. When you run the system utility (or
call a program for that matter) it will spawn a new job to run that in.
If you got the parmeters right, you could send a message to a call
stack entry in that newly spawned job, but what good would that do? You
can't send it to the caller, since the caller isn't in the same job in a
QShell scenario.

If you would please explain what you're trying to do, I'd be happy to
see if I can help... but right now, I just can't fathom what you're
trying to accomplish.


John McKee wrote:

I used teh following QSH command:

system 'call pgm(qmhsndpm) parm('CPF9898' 'QCPFMSG *LIBL' 'TEST MESSAGE' '1
2' '*ESCAPE' '*SYSOPR' '3' ' ' ' ')'
CPF24B3: Message type MESSAGE not valid.
CPC2206: Ownership of object QZSHSYSTEM in QTEMP type *USRSPC changed.

Issues I have: No idea what should be used just after the *SYSOPR parameter.
Coding a 3 is just guesswork.

Is the CPF24B3 related to the value of '3'? The command SNDPGMMSG does not show
a MESSAGE parameter.

I was wondering if SNDPGMMSG was restricted based on a parameter, but the API
that actually sends the message did not need that restriction.

John McKee

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.