× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I don't actually need alternatives, my procedure is working. It isn't a big
deal, so I will share the source:


// ------------------------------------
// Receive a completion message
// Receives a completion message from the program message queue
//
// Parameters:
// messageId - The message id of the message received. For impromptu
// messages, this will be blank.
// messageData - Message data, or impromptu message for the received
message.
// messageFile - The qualified name of the message file containing the
// message. The first 10 characters is the messafe file name,
// the second 10 characters is the library. For impromptu
// messages, this will be blank.
// ------------------------------------
dcl-proc RcvCompMsg Export;
dcl-pi *n OpDesc;
messageId Char(7);
messageData Varchar(32767) options(*varsize);
messageFile LikeDs(qualName_t);
end-pi;

dcl-ds ec LikeDs(errCode_t) Inz(*likeds);

dcl-ds msg LikeDs(RCVM0200_t) Based(pMsg);
dcl-s msgInfo Char(2048) Inz('');
dcl-s pMsg Pointer Inz(%addr(msgInfo));
dcl-s msgDta Char(1024) Based(pMsgDta);
dcl-s pMsgDta Pointer Inz(*null);

dcl-s dataType Int(10);
dcl-s curlen Int(10);
dcl-s maxLen Int(10);
dcl-s fc Like(feedback_t);

qmhrcvpm(msgInfo: 2048: 'RCVM0200': '*': 1: '*COMP': '': 0: '*OLD': ec);
if ec.messageId <> '';
SendEscMsg(ec.messageId: ec.messageData: QCPFMSG);
endif;

messageId = msg.messageId;
messageFile = msg.messageFile;
messageData = '';
ceegsi(%parmnum(messageData): dataType: curLen: maxLen: fc);
if %subst(fc: 1: 4) = x'0000';
pMsgDta = %addr(msg) + %size(msg);
if msg.dataLenRtn > 0;
messageData = %subst(msgDta: 1: %min(msg.dataLenRtn: maxLen));
endif;
endif;
end-proc;

Prototypes for QMHRCVPM and CEEGSI are in a header file. So I want to know
how big the returned message could be, I believe 32K is big enough for any
message, but if the caller provides a shorter parameter, then I want to
know how much space is available so I don't overflow buffers. It would be
nice in this case if I could just use %LEN(*MAX) to interrogate the maximum
size of the Varchar passed to the procedure. I am using CEEGSI for that,
but it isn't nearly as easily understood. I know that %SIZE and %ELEM are
compile time constants, but they could be implemented as run time values as
well if they used the OpDesc to get the values for the parameter as passed.

There has to be code to support OPTIONS(*VARSIZE). It just seems incomplete
since %SIZE, %ELEM, and %LEN(*MAX) do not return the appropriate values
when it is present, but they could.

On Wed, Dec 19, 2018 at 4:00 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

I think maybe what the manual is telling you is that normally the called
program/procedure makes use of the operational descriptors - for example to
provide the value for %Parms.

The scenario you describe is somewhat unusual. Mostly because if the
proto is described as varchar then even with an opDesc you would have
problems if a large field were passed as it would need a 4 byte length
header not a two. Must do some checking on that because it doesn't make
sense.

As to %Len(fieldname) - it will give you the length passed. You would use
the CEE APIs to interrogate how big it could have been. Really only of any
use when you intend to change the value in the field.

If you could explain why you are using this rather odd combination and
what you are trying to do we could offer alternatives.

OpDesc is not used that often partly because the implementation is
incomplete and partly because different languages provide different levels
of descriptors by default.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Dec 19, 2018, at 2:11 PM, Mark Murphy <jmarkmurphy@xxxxxxxxx> wrote:

The documentation is somewhat vague on Operational Descriptors. But I
read
this:


Descriptors are normally accessed directly by a called procedure
according
to the semantics of the HLL in which the procedure is written. Once a
procedure is programmed to expect operational descriptors, no further
handling is usually required by the programmer. However, sometimes a
called
procedure needs to determine whether the descriptors that it requires are
present before accessing them. For this purpose the following bindable
APIs
are provided:

- Retrieve Operational Descriptor Information (CEEDOD) bindable API
- Get String Information (CEEGSI) bindable API



in the Knowledge Center, here:

https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/ilec/apiopd.htm

That seems to me to be saying that the only thing I should need to do
with
these API's is to determine if the operational descriptor is present or
not, but that the HLL (in this case RPGLE) should process the operational
descriptor.

So I have a procedure defined with OPDESC, and a Varchar defined with
OPTIONS(*VARSIZE). The Knowledge Center tells me this:


When OPTIONS(*VARSIZE) is specified, the passed parameter may be shorter
or
longer in length than is defined in the prototype. It is then up to the
called program or subprocedure to ensure that it accesses only as much
data
as was passed. To communicate the amount of data passed, you can either
pass an extra parameter containing the length, or use operational
descriptors for the subprocedure. For variable-length fields, you can use
the %LEN built-in function to determine the current length of the passed
parameter.


Does that mean that all I have to do is use %LEN(*MAX) and it will
interrogate the opdesc to determine the maximum length of the VARCHAR
that
was passed? or will %LEN(*MAX) just tell me what I defined as the maximum
length in the procedure interface?
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx 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 the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.