Re: Strange error on calling API QMHMOVPM

Well, the situation solved itself mysteriously. For the time being I added a (bulky) loop with QMHRCVPM and QMHSNDPM, conditioned by the error received from QMHMOVPM. While debugging all of a sudden the program did not enter the loop. Huh? QMHMOVPM did not return an error anymore.

In the meantime I discovered that 'on-exit' adds an extra call level (probably mentioned by Barbara when on-exit was announced, but it didn't stick). So QMHMOVPM tries to move the messages for the extra call level; that obviously does not give the result I was trying to achieve. I removed the on-exit (and early returns) and now everything is working proberly.

Strange.

Joep Beckeringh


Op 9-11-2021 om 09:11 schreef Joep Beckeringh via RPG400-L:

Hello all,

I've got the following strange situation:

In a procedure in a program I call a few things and in the end I want to move messages that I received to the calling procedure, that uses a display file with a message subfile. So I call API QMHMOVPM, but that reports error CPF24A5 'Value of &1, for number of message types, not valid.'. Message data is X'00000003', which looks like a 4 byte integer containing the value 3, like it should.

Funny thing is, I have exactly the same call in several other programs and they don't give an error (I checked in debug).

The prototype for the call is in an include member and looks like this:

// Move program messages
dcl-pr QMHMOVPM extpgm;
  MsgKey char(4) const;
  MsgTyp char(40) const options(*varsize);
  MsgTypCnt uns(10) const;
  CstEnt char(10) const;
  CstCnt uns(10) const;
  ErrDts char(1) options(*varsize);
end-pr;

And the call looks like this:

  // Move program messages
  QMHMOVPM(MsgKey: MsgInf: MsgCnt: '*': 1: ErrDts);

MsgKey is char(4), MsgInf char(30) and contains '*COMP *DIAG *INFO', MsgCnt = uns(10) and contains 3.

Only special thing about this program is that the calling procedure is recursive (the program is an IFS browser; if you choose a directory it starts a new instance of the procedure). But I fail to see how that influences the call to QMHMOVPM.

Anyone any bright ideas about this?

Joep Beckeringh
Pantheon Automatisering