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




What happens in the program when you run it under STRDBG?



Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill



Robert Rogerson
<rogersonra@gmail
.com> To
Sent by: "RPG programming on the IBM i /
rpg400-l-bounces@ System i" <rpg400-l@xxxxxxxxxxxx>
midrange.com cc

Subject
06/02/2010 09:25 Re: Setll and Reade not working as
AM esxpected....


Please respond to
RPG programming
on the IBM i /
System i
<rpg400-l@midrang
e.com>






I created a command which calls the RPG but the Setll and Reade is still
failing.

CMD PROMPT('Call ACP0074R')

PARM KWD(INVOICE) TYPE(*CHAR) LEN(22) RSTD(*NO) +
PROMPT('Enter Supplier Invoice')
PARM KWD(DUNSNBR) TYPE(*CHAR) LEN(80) RSTD(*NO) +
PROMPT('Enter Supplier DUNS Number')

Just for my knowledge, this should have handled the 32A parameter limit.
Correct?

Thanks,

Rob



On Wed, Jun 2, 2010 at 8:55 AM, Robert Rogerson
<rogersonra@xxxxxxxxx>wrote:

Scott,
(Maybe the invoiceIn or dunsnbrIn parameter is longer than 32A?)

The input parameters are defined as follows:

d Main pr Extpgm('ACP0074R')
d invoiceIn...
d Like(invoice) const
d dunsnbrIn...
d Like(dunsnbr) const

And in the DDS for EDII810JH
A R EDII810JHR
A TEXT('810 Incoming Invoice
A Intermediate JBA Header')

A INVOICE 22A TEXT('Invoice Number')
A DUNSNBR 80A TEXT('Duns Number')

So yes the dunsnumber is longer than 32A. Does this make a difference?
When I call the program (from the command line for testing) I enter:
call acp0074R ('0091560147' '2492294020200')

I then do a Setll and Reade with invoiceIn and dunsnbrIn.

Thanks Scott, I did some searching and it sounds like the problem is on
the
duns number exceeding 32A. I'm going to create a command wrapper to see
if
that doesn't fix the problem (I think it should) and report back on my
findings.

Thanks to all that responded,

Rob


On Tue, Jun 1, 2010 at 5:20 PM, Scott Klement
<rpg400-l@xxxxxxxxxxxxxxxx>wrote:

Maybe the invoiceIn or dunsnbrIn parameter is longer than 32A?

Or perhaps instead of passing blanks, the caller didn't pass the
parameters at all?

Can you provide more information about how these parameters are defined,
and how values are assigned to them? Or better yet, can you show us
how to reproduce the problem?


On 6/1/2010 3:55 PM, Robert Rogerson wrote:
I added the rc to check the values of %Equal() and %Eof() while in
debug.
When I pass an invoice and dunsnumber from the file and debug the
program
the %Equal() after the Setll has a value of '0' indicating an exact
match
was not found. I check the file and yes the record does exist. I
also
tested this with SQL adding the invoice number and dunsnumber passed
to
the
program and the record was returned.

I'm stumped...any ideas?

--
This is the RPG programming on the IBM i / System i (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 is the RPG programming on the IBM i / System i (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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.