×
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.
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))
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.
midrange.com
