RE: Problem with message subfile

I agree about the binding of a module. If I remember correctly from way
back when I started this (guessing 6 months ago), I tried a service program
and the messages did not display in the message subfile (like they are not
doing with the module).

If the program is ABC and the service program is XYZ, I found the messages
were sent to XYZ (value in sdspgman of the service program). However, as I
stated in the original post, if I include the copybook in my program, it
sends the messages to ABC (value in sdspgmnam in the program) and they
appear in the subfile.

I guess I was expecting the sdspgmnam to always be the program name and work
the same as a copybook included in the program whether the function was in a
module or in a service program.

So, is there a way to send the message from the service program and have it
end up in the subfile message? I'd rather not add parameters because I have
this function called from all over the place and really don't want to have
to change all of them.


-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Alan
Campin
Sent: Saturday, August 8, 2020 8:11 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Problem with message subfile

When you say it doesn't work, do you mean the subfile messages don't appear.
If yes, message are set to the procedure name if you are using a procedure.
You have to procedure that do the subfile message processing it needs be
passed the procedure name where the screen is running.

On the other hand, you may mean something completely different.

As far as binding in a module, I think that is a terrible idea(My opinion
only). Reusable logic should be in a service program.

On Sat, Aug 8, 2020 at 5:00 PM <smith5646midrange@xxxxxxxxx> wrote:

Does being in a module affect the call stack? I didn't think that it
did.

If I include the copybook in my program, it works. If I use the same
copybook and compile to a module and bind the module to my program, it
does not.

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Carel
Sent: Saturday, August 8, 2020 5:53 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Problem with message subfile

Adding it in a sub-procedure, you add 1 to the call stack.

Think your problem is the call stack value on the API.


Op 8-8-2020 om 23:11 schreef smith5646midrange@xxxxxxxxx:

For MANY years I have used the same messaging logic in 5250 programs
which involves using a copybook and now that I have made a slight
change to it, I can't figure out how to fix what I broke.



I have always used the variable sdsPgmNam which is part of the SDS.
Rather than including the copybook that has my SndMsg function in
every program, I decided to create a module (and will probably
change to use a service program at some point) with this and several
other functions and bind it in at compile time. The problem that I
have run into is that when I call the function now, sdsPgmNam is the
name of the module, not the name of the program. I've tried using
some other values such as *PGMBDY but I've apparently got something
wrong because I can't get the message into my subfile. Can anyone
point me in the

right
direction on this?

Here is the SDS.

d sds

d sdsPgmNam *proc



Here is the subfile.

A R SUBMSG SFL

A SFLMSGRCD(27)

A MSGKEY SFLMSGKEY

A SDSPGMNAM SFLPGMQ(10)



Here is the SndMsg Function

p SndMsg b export

d SndMsg pi

d SndMsgData 256 const



d SndMsgDLen s 9b 0 inz(256)

d MsgQNB s 9b 0 inz(0)

d MsgKey s 4a



SndMsgDLen = %len(%trim(SndMsgData));

APIError.ErrPrv = %size(APIError);

callp QMHSNDPM(*blanks

:'QCPFMSG QSYS'

:SndMsgData

:SndMsgDLen

:'*INFO'

:sdsPgmNam

:MsgQnb

:MsgKey

:APIError);

endif;

p e

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list To post a
message email: RPG400-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com