Re: Spot the difference

Barbara,

I tried your suggestion, and it made sort of a difference.

Now I see the message when I exit the program.  But that's not what I need,
I want the message to show immediately, in the program, telling the user
that his list has printed, while remaining in the program.  Changing the
stack offset to 1 did not work either.

What puzzles me is that the Call does exactly what I want it to do.

I don't know if this is important, but it's a small program using a panel
group, not a display file.

Thanks,

Peter Colpaert
Application Developer

Honda Europe NV
Langerbruggestraat 104
B-9000 GENT
Peter.Colpaert@honda-eu.com
Tel: +32 9 2501 334
Fax: +32 9 2501 231
----------
Yoda of Borg are we: Futile is resistance. Assimilate you, we will.
----------





Barbara Morris <bmorris@ca.ibm.com>@midrange.com on 19/06/2002 20:48:33
Please respond to rpg400-l@midrange.com
Sent by:  rpg400-l-admin@midrange.com

To:   rpg400-l@midrange.com

cc:

Subject:  Re: Spot the difference


Peter Colpaert wrote:
>
> I am having a very weird problem in one of my programs, when using the
> QMHSNDPM API.
>
> ...
>
> When I use the normal call, the message is displayed on the screen, but
> when I use the prototyped CALLP, it only shows in the joblog.
>

Peter, I see the same results for both the calls (msg goes to the joblog
only, what I would expect for a *INFO message sent to stack offset 0).

To get the message to flash on the bottom of the screen, you have to
send a message of type *STATUS to pgmq *EXT.

To get it to stay there (assuming your program is the one called from
the command line), you have to send the message to the caller of your
program.  For OPM programs, this means a stack offset of 1.  For ILE
programs, a stack offset of 2.

By the way, when developing programs using APIs, I find it saves a lot
of time to set the first subfield of the API error-code parm to zero, so
that any errors will cause the program to crash, leaving the API error
message in the joblog.  Once you have it working, change it back to a
non-zero value and add whatever logic you need to check the error code
after you call the API.  Although if you don't expect to get errors
ever, it might be better to leave it as 0 even in production, so you'll
have some record (joblog) if something ever does go wrong.

Barbara







______________________________________________________________________
The information contained in this communication is confidential and may be
legally privileged. It is intended solely for the use of the individual or
the entity to whom it is addressed and others authorised to receive it. If
you have received it by mistake, please let the sender know by e-mail reply
and delete it from your system.
If you are not the intended recipient you are hereby notified that any
disclosure, copying, distribution or taking any action in reliance of the
contents of this information is strictly prohibited and may be unlawful.
Honda Europe NV is neither liable for the proper and complete transmission
of the information contained in this communication nor for any delay in its
receipt.