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



Barbara,

Thanks for your explanation... but I'm completely lost. I understand that I have UTF8 data in my RPG variable.

I tried this:
x = %scan(%UCS2('^XZ') : %UCS2(base64decoded));

Result is x = 0.

I know it's there because when I write out base64decoded to the IFS file, I can see it:
--- more above ---
USPS TRACKING #
^FS
^FO73,949^BY3^BCN,152,N,N,N,D^FD42022302>89461211699000980723836^FS
^FO0,1147^FB812,1,2,C,0^A0N,34,34^FD
9461 2116 9900 0980 7238 36
^FS
^FO0,1189^GB812,0,6,B,0^FS
^FO548,310^FB120,1,2,C,0^A0N,40,40^FD
C022
^FS
^FO545,304^GB126,50,2,B,0^FS
^XZ

Code used to write is as follows:
labelData = %subst(base64Decoded:1:len);
flag = o_wronly + o_creat + o_ccsid + o_excl;
mode = s_irusr + s_iwusr + s_iroth + s_iwoth;
fd = open(Stmf:flag:mode:1208:0);
Ifs_Write(fd:labelData);
Ifs_CloseFile(fd);

I not only need to scan/replace for '^XZ', I need to add a string of my own (literals and variable data) followed by '^XZ'.
(basically inserting a string at the end of the data to print some extra lines on the label)

Preferably, I would like to do this before writing to the IFS.

Right now I'm at a loss as to how to accomplish this.

Jon... I haven't used Green Screen debug for years... but I tried. It only shows me the first 1024 bytes when evaling the variable. Can this be seen in RDI?

Greg



-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: Tuesday, August 18, 2020 10:06 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Manipulating a decoded UTF8 string

On 2020-08-18 4:57 p.m., Mark Waterbury wrote:
...
Note that if you are doing anything "tricky" like declaring a variable to be a certain CCSID on the "declare" statement (or D-spec), you cannot then use a literal in the search, such as coding "%scan('^XZ', base64decoded) " because you do not know what the compiler will decide should be the correct CCSID to use for any "literals" coded in your program.  Normally, I think it defaults to the job's CCSID of the job in which the program was compiled ... :-o
...

Literals are saved in the CCSID that the source file is read in.
Normally, the source is read in the CCSID of the main source file, but
you can use the TGTCCSID parameter to specify a different -EBCDIC-
CCSID, or *JOB.

But by default, RPG interprets the literal in the CCSID of the job the
program is running in.

If you code CCSID(*EXACT) in the H spec, RPG will interpret saved
literals correctly.

Another way to have literals interpreted correctly is to code them as
UCS-2 literals, such as %UCS2('My string').

But %SCAN doesn't allow type or CCSID difference for the operands, so
you'd have to use %CHAR or %UCS2 to get the other operand to the same CCSID.

%scan(%UCS2('^XZ') : %UCS22(base64decoded))


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.