× 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.



Hi Tom,

Thanks for your prompt reply. I made the necessary changes and it seems to
have sorted things out. Thanks very much!

Nathan

----- Original Message ----- 
From: "Tom Liotta" <qsrvbas@xxxxxxxxxxxx>
To: <rpg400-l@xxxxxxxxxxxx>
Sent: Wednesday, August 10, 2005 12:34 PM
Subject: RE: QRCVDTAQ (Receive Data Queue) program


> rpg400-l-request@xxxxxxxxxxxx wrote:
>
> >   6. Re: QRCVDTAQ (Receive Data Queue) program (Nathan Hiley)
> >
> >My code is as follows:
> >
> >DCL VAR(&QNAMEO)  TYPE(*CHAR) LEN(10)
> >DCL VAR(&KEY)     TYPE(*CHAR) LEN(87) (key passed in)
> >DCL VAR(&WAITQ)   TYPE(*DEC)  LEN(5 0) (passed in - set to 7 seconds)
> >DCL VAR(&RPYDTA)  TYPE(*CHAR) LEN(2378) VALUE(' ')
> >DCL VAR(&SENDER)  TYPE(*CHAR) LEN(10)  VALUE(' ')
> >DCL VAR(&SNDLEN)  TYPE(*DEC)  LEN(3 0) VALUE(0)
> >DCL VAR(&RPYLEN)  TYPE(*DEC)  LEN(5 0) VALUE(0)
> >DCL VAR(&RPYLEC)  TYPE(*CHAR) LEN(5) VALUE(' ')
> >:
> >:
> >CALL PGM(QRCVDTAQ) PARM(&QNAMEO '*LIBL     ' &RPYLEN &RPYDTA &WAITQ 'EQ'
+
> >                        &KEYLEN &KEY &SNDLEN &SENDER)
> >CHGVAR VAR(&RPYLEC) VALUE(&RPYLEN) (MCH3601 on this line)
> >
> >The data queue in &QNAMEO is a standard, keyed queue, key length=87,
include_sender_id=*no, max_length=11721.
> >
> >Can anyone see a problem with the above? If not, what else could be the
cause of the problem. Any help would be greatly appreciated.
>
> Nathan:
>
> I haven't looked in detail, but was immediately caught by three elements.
First is this source line:
>
> >DCL VAR(&RPYDTA)  TYPE(*CHAR) LEN(2378) VALUE(' ')
>
> Second is this statement of yours:
>
> >The data queue in &QNAMEO is a standard, keyed queue, key length=87,
include_sender_id=*no, max_length=11721.
>
> And third is the absense of optional parameter group 2 for the API. That
parameter group includes the Size of data receiver parm. Without telling the
API how big your receiver variable (&RPYDTA) is, there's no telling what
memory might get blasted when the API returns a message that's longer than
2378.
>
> Just the kind of thing that could contribute to MCH3601 errors, AFAIK.
>
> In fact, since the maximum size of a data queue message from that data
queue is longer than the largest possible CL variable, you probably should
expect a problem sooner or later regardless of what messages are currently
on the queue (unless you limit what the API returns).
>
> Tom Liotta
>
> -- 
> Tom Liotta
> The PowerTech Group, Inc.
> 19426 68th Avenue South
> Kent, WA 98032
> Phone  253-872-7788 x313
> Fax    253-872-7904
> http://www.powertech.com
>
>
> __________________________________________________________________
> Switch to Netscape Internet Service.
> As low as $9.95 a month -- Sign up today at
http://isp.netscape.com/register
>
> Netscape. Just the Net You Need.
>
> New! Netscape Toolbar for Internet Explorer
> Search from anywhere on the Web and block those annoying pop-ups.
> Download now at http://channels.netscape.com/ns/search/install.jsp
> -- 
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
>



----------------------------------------------------------------------
This message is intended for the addressee named and may contain
confidential information. If you are not the intended recipient,
please delete it and notify the sender. Views expressed in this
message are those of the individual sender, and are not necessarily
the views of REVS and the Office of Fair Trading.

The contents of this message has been automatically scanned, and
whilst all care is taken, it is the recipient's responsibility to
ensure that any attachments are scanned for viruses prior to use.
----------------------------------------------------------------------

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.