Re: Removing blanks from a varning length field. -- RPG400-L

As I cannot imagine Scott inserting those DLEs I have to assume they are in
the XML document. So long as whoever sends the XML document retains this
DLE characteristic (whether it be the encryption program or the caller of
the encryption program) of padding the actual text then the %scan and
%subst approach should work (or simply trimming all blanks and DLEs). This
would NOT necessarily work with other senders of the XML -- for instance
one I might send for another application as I know I don't embed DLEs.

On Wed, Nov 20, 2019 at 10:23 AM Rishi Seth <rishiseth99@xxxxxxxxx> wrote:

Hi,

Thanks much.

With this one line of code change i am able to find only correct and exact
decrypted value being written in my test file now.

you can refer this link for more details regarding this unixcmd:-
*https://www.scottklement.com/unixcmd/
<https://www.scottklement.com/unixcmd/>*

---> This is a tool to help simplify the process of running QShell or PASE
commands from RPG or CL. For RPG, the tool implements a SPECIAL file that
you open and connect to a QShell or PASE command that you want to run. When
you read the file, you're reading the output of the command. When you write
to the file, you're writing data to the command. For CL, it provides
OPNPIPE, RCVPIPE, SNDPIPE and CLOPIPE commands that open the Unix and
send/receive data from it, very similar to the way you use files in CL.

Now can i be sure let's say this worked correctly for current xml file
which had some encodedexchange data in it let's say if i get another
different xml file which may have different encodedexchangetoken value in
it as i mentioned in my previous email so based on those different
inputs(different encodedexchangetoken values based on different XML files)
the value of decrypted result field currently so called 'record' in this
program will also vary so those different decrypted values may also have
those junk values inside them so will this suggested change be able to
handle all those different unforeseen decrypted values as well, which
might also have similar or different junk values inside them? because each
time I can not debug and check what is the decrypted value and then each
time can't amend my program right? so what should be the long run solution
for this problem or
this is the only solution which will help to overcome all those unseen
probable junk values which might appear inside that decrypted values so
that each time i could write correct and exact decrypted values in my
testfile.

If No,then how can i make my program capable enough so that it could handle
those junk values as well currently program code mentioned in below link
works well:-

*https://code.midrange.com/c8f9353ada.html
<https://code.midrange.com/c8f9353ada.html>*

Thanks

On Wed, Nov 20, 2019 at 3:33 PM Bruce Vining <bruce.vining@xxxxxxxxx>
wrote:

Oops, just noticed I used the wrong numbers...

Where I typed 65 should be 49 (DLE start byte) and 80 should be 65 (blank
start byte) so

eval record = %trimr(%subst(record :1 :80) : x'10');

should be:

eval record = %trimr(%subst(record :1 :64) : x'10');

Ahh the perils of building a test case on simplified data (that is, I did
not recreate your entire data stream...just a few representative bytes).

As AES works with 16 byte data blocks I suspect (but don't know for a

fact

as I didn't bother decrypting using the i APIs) that the XML might also
contain the DLEs as I'm not sure how UNIXCMD is written. If in fact the
DLEs are embedded then just scanning for the first DLE might be

sufficient

(no trimming needed, just substringing).

On Wed, Nov 20, 2019 at 9:09 AM Bruce Vining <bruce.vining@xxxxxxxxx>
wrote:

Debug is showing that the UNIXCMD program is returning data link escape
(x'10') values rather than blanks for bytes 65 - 80, and then blanks
(x'40') starting at 81. If you somehow know that the actual data

length

being sent is 80 bytes (which it appears from your notes that you do)

then

eval record = %trimr(%subst(record :1 :80) : x'10');

and record should now be all blanks following byte 64.

Otherwise trim blanks and DLEs from record OR, as this is EBCDIC data,
scan for the first DLE and substring out bytes 1 thru the DLE position

less

1. Either way should get the job done based on your current XML

document.

On Wed, Nov 20, 2019 at 8:01 AM Rishi Seth <rishiseth99@xxxxxxxxx>

wrote:

Hi,

Thanks.

EVAL N1 = %LEN(OUTREC);

DSPLY N1;

" This should display the correct length of your token value.

If

not, then there are garbage characters (not blanks) being introduced
somewhere in the above process."

----When I debug I get N1 = 64 which is incorrect which ideally should
have
been 48 as per current decrypted value( if you calculate the length of
actual decrypted value which is actually in current scenario is '
*707fbe32-0dbc-41e0-888f-5bc40de8c20d2P9AMPCTQ4CZ*' ) of '
*encodedExchangetoken'* field which is read from input XML file and

comes

in record field after this openssl command in the mentioned program.

so value of N1=64 in debug mode which clearly indicates that we have
some
garbage value apart from decrypted value in record field here and I am
struggling to remove that garbage value only.

RCDLEN = 500 is incorrect then what should be correct length on fly

so

that i can set it as per exact decrypted value of record field which
should not contain any garbage value in it?

Please see below values obtained in debug session after following

given

instructions:-

> EVAL encodedExchangeToken:x 96

00000 0058A4F3 E5A3D587 86A8E6E4 F98681E9 -

.ìu3VtNgfyWU9faZ

00010 83F3C981 81F8E9E6 82C5F5E4 E9C38694 -

c3Iaa8ZWbE5UZCfm

00020 C3F1F7A8 C1F4D4A8 E6F08788 8693A3F9 -

C17yA4MyW0ghflt9

00030 84D5D8D5 C497C383 87D4E989 C76192E7 -

dNQNDpCcgMZiG/kX

00040 D7C5F4A5 A5F2C3C8 D3F9F3C2 F489D289 -

PE4vv2CHL93B4iKi

00050 D6C4C8A7 A784E5C1 7E7E0000 00000000 -

ODHxxdVA==......

> EVAL record:x 96

00000 F7F0F786 8285F3F2 60F08482 8360F4F1 -

707fbe32-0dbc-41

00010 85F060F8 F8F88660 F58283F4 F08485F8 -

e0-888f-5bc40de8

00020 83F2F084 F2D7F9C1 D4D7C3E3 D8F4C3E9 -

c20d2P9AMPCTQ4CZ

00030 10101010 10101010 10101010 10101010 -

................

00040 40404040 40404040 40404040 40404040 -

00050 40404040 40404040 40404040 40404040 -

Bottom
Debug . . .

Thanks

On Wed, Nov 20, 2019 at 3:54 AM Bruce Vining <bruce.vining@xxxxxxxxx>
wrote:

I apologize if you've done these steps before, but could you:

1. Enter debug of your program
2. Set a breakpoint on the statement
eval encodedExchangeToken =%trimr(encodedExchangeToken);
3. Set a second breakpoint on the statement
eval record = %trimr(record);
4. Run the program
5. At the breakpoint set in step 2 run
eval encodedExchangeToken:x 96
6. Resume the program and at the breakpoint set in step 3 run
eval record:x 96
7. Post the displayed results of steps 5 and 6
8. Post the contents of
/home/I0RS01HU/INPUT.xml

On Tue, Nov 19, 2019 at 11:36 AM Rishi Seth <rishiseth99@xxxxxxxxx>

wrote:

I think we are getting diverted from main topic what i meant was

that

even

i tried as you said on fly that flat file should be created with

exact

length of that decrypted value even that i tried please see below

code

but n1 variable which is holding the value of %len(outrec) in

debug

mode

tells it's value to be 64 that means still after doing those

%trimr

on

field or data structure as well have some extra junk value because

length

of decrypted value is 48 only so 64-48 =16 these 16 length is

full

of

garbage which i don't want to write in my flat file .

FUNIX IF F 1000 SPECIAL PGMNAME('UNIXCMD')
F PLIST(UNIXPARM) USROPN
F*QSYSPRT O F 1000 PRINTER
dencodedExcha...
dngeToken s 500 VARYING

DPOS2 S 5U 0
D cmd s 5000a
D mode s 1A inz('P')
DN1 S 2P 0
D Åcommand s 512a
d QCMDEXC PR ExtPgm('QCMDEXC')
d command 500a const
d clength 15p 5 const

D record ds 1000
D outrec s 1000 varying inz

C UNIXPARM PLIST
C PARM CMD
C PARM MODE
/free
RECORD = *BLANKS;
OUTREC = *BLANKS;
XML-INTO encodedExchangeToken %XML('/home/I0RS01HU/+
INPUT.xml':'doc=file case=any path=+
TokenExchangeResponse/encodedExchangeToken');
eval encodedExchangeToken =%trimr(encodedExchangeToken);
cmd = 'echo ' + '''' + encodedExchangeToken + ''' !

openssl

+

enc -d -aes-128-ecb -K 363631653237354f494d31554c594c4a

+

-nopad -nosalt -base64 -A';
open UNIX;
read UNIX record;
dow not %eof(UNIX);
eval record = %trimr(record);
eval outrec = %trimr(record);
eval outrec = %trimr(outrec);
EVAL N1 = %LEN(OUTREC);
DSPLY N1;
//Delete the TESTFILE
Åcommand = 'DLTF FILE(rishi/TESTFILE)';
QCMDEXC(%trim(Åcommand): %len(%trim(Åcommand)));
Åcommand = *blanks;
Åcommand = 'CRTPF FILE(RISHI/TESTFILE) RCDLEN(500)';
QCMDEXC(%trim(Åcommand): %len(%trim(Åcommand)));
//Write into file
EXEC SQL
INSERT INTO rishi/TESTFILE VALUES (:outrec);
// dsply %subst(outrec:1:48);
read UNIX record;
enddo;
close UNIX;
*inlr = *on;
/end-free

On Tue, Nov 19, 2019 at 5:06 PM <dlclark@xxxxxxxxxxxxxxxx> wrote:

"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> wrote on

11/19/2019

10:52:25 AM:

sorry i did not understand what you mean but let me explain

somethings

clearly:-

1) decrypted output of this AES128 algorithm is uncertain.

One step at a time... There are only two things that

you

can

do

about this AES128 algorithm you mention. It must either accept

a

valid

varying-length parameter and handle it as such or there must be

a

separate

parameter which allows you to pass a length value in addition to

the

data

to be encrypted/decrypted. No one can answer those issues for

you

(unless

they are familiar with the process of which you are speaking).

You

must

be able to analyze the AES128 algorithm to determine which of

the

above

two requirements can be met.

Sincerely,

Dave Clark
--
int.ext: 91078
direct: (937) 531-6378
home: (937) 751-3300

Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331

*********************************************************************************************

This email message and any attachments is for use only by the

named

addressee(s) and may contain confidential, privileged and/or

proprietary

information. If you have received this message in error, please
immediately notify the sender and delete and destroy the message

and

all

copies. All unauthorized direct or indirect use or disclosure of

this

message is strictly prohibited. No right to confidentiality or

privilege

is waived or lost by any error in transmission.

*********************************************************************************************

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
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 IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
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

--
Thanks and Regards,
Bruce
931-505-1915
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
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 IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
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

--
Thanks and Regards,
Bruce
931-505-1915

--
Thanks and Regards,
Bruce
931-505-1915
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
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 IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
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