× 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 guess my question is why would you expect this to work? You are passing a
pointer to a 17 byte field to program that is expecting 20 bytes.

What is in bytes 18 to 20 can be anything. Whatever is in memory.

Next question. Why are you writing a program instead of service program?

MaskedValue = GetMaskedValue(UnMaskedValue);

dcl-proc GetMaskedValue Export;
dcl-pi *N VarChar(20);
InUnMaskedValue VarChar(20) Options(*Trim) Value;
end-pi;

If you pass a twenty byte it will create a twenty byte field and move the
twenty bytes into it and trim out the blanks.

If you pass a 17 byte field it will move the 17 bytes into a 20 byte field
and trim the blanks.

I was thinking that you could use OPDESC but this only going to work if you
call a procedure. It won't work on a program call.

Maybe pass them as VarChar?

.



On Tue, May 16, 2017 at 4:41 PM, Dan <dan27649@xxxxxxxxx> wrote:

I am at my wit's end. I thought I knew this stuff, but maybe I've just
been lucky before with scenarios that didn't cause problems.

I created a utility program that masks account numbers, changing all but
the last 4 digits to asterisks. It has two parameters, both 20 byte
characters, the first is input, the second is output. The program that
will call this utility program has a choice of passing either two
20-character fields or two 17-character fields. The call using the
20-character fields as parameters works fine. The call using the
17-character fields as parameters does not. I've tried several D-spec
keywords, VARYING, OPTIONS(*VARSIZE), maybe others, to no avail. VARYING
doesn't work, I think, because the fields in the calling program that I
want to pass as parameters are not also VARYING; the compile issued RNF7535
(The type and attributes of parameter 1 do not match those of the
prototype). I've created a short calling program that mimics what is
happening in the larger program that I want to use the new utility program
in:

d CA9802R pr ExtPgm( 'CA9802R' )
d 20 Options( *VarSize )
d 20 Options( *VarSize )

d AC_ACCT s 20 Inz
d zz_ACCT s 20 Inz
d XX_OACHACT s 17 Inz
d zz_OACHACT s 17 Inz

ac_Acct = '12345678901234567890';
Callp CA9802R( ac_Acct : zz_Acct );
returns '****************7890'

XX_OACHACT = 'Just11Chars';
Callp CA9802R( xx_OACHACT : zz_OACHACT );
returns '**************** '

*inLR = *on;
DUMP(A);

Program CA9802R:
h DftActGrp( *No )
d CA9802R pi
d p_Account# 20a Options( *VarSize )
d p_MaskedAcct# 20a Options( *VarSize )

d MaskAccount# pr 20a
d AccountNbr 20a Const Options( *Trim )

p_MaskedAcct# = MaskAccount#( p_Account# );
*inLR = *on;
Return;

p MaskAccount# b
d MaskAccount# pi 20a
d AccountNbr 20a Const Options( *Trim )

d wAccountNbr s 20a
d Length s 3 0
d #ofAsterisks s 3 0
d i s 3 0

wAccountNbr = AccountNbr;
Length = %len( %trimr( wAccountNbr ));
If Length > 1;
If Length >= 8;
#ofAsterisks = Length - 4; // Mask all but last 4 digits
Else;
#ofAsterisks = Length / 2; // Mask half of the digits
Endif;
For i = 1 to #ofAsterisks;
%subst( wAccountNbr : i : 1 ) = '*';
Endfor;
Endif;
Return wAccountNbr;
p MaskAccount# e

When I debugged CA9802R, the p_Account# field for the second call had a
junk character in position 18. I understand it's because the parameter
passed from the calling program is 17 bytes, but I thought one of the
"vary*" keywords would allow me to do this without having to pass a length
parameter.

What am I missing here?

- Dan
--
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: 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.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


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.