|
On Oct 13, 2023, at 6:20 PM, Suren K <suren7437@xxxxxxxxx> wrote:
Hi Scott and Everyone,
I submitted an idea for this one in the IBMi Idea Portal. Link as below
https://ideas.ibm.com/ideas/IBMI-I-3817
If you think this idea is worth implementing, please vote for this idea.
Regards,
Suren
On Fri, Sep 15, 2023 at 2:48 PM Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
wrote:
Suren,--
RPG does not currently provide that information to the parser.
That is something that would've been useful to me, too, at times.. so
if you were to submit an idea to IBM, I'd be willing to vote for it.
My suggestion would be for IBM to add another routine to the
'environment' that would allow the parser to retrieve details about the
variable you are mapping data into. Ideally, this would NOT just be
"the current field" but would allow you to retrieve the entire layout of
the variable you're working with, possibly requiring multiple calls?
Conceptually, this would be something like this:
dcl-s v int(10);
dcl-ds info likeds(QrnDiVarInfo_t);
v = QrnDiOpenResultVar(handle);
dou rc <> 0;
rc = QrnDiReadResultVar(v: handle: Info);
if rc = 1;
leave;
endifl;
// "info" now contains stuff like the name, type (packed, zoned,
varchar, char, etc), length, decimal places, ccsid, maybe other things.
There could also be custom "types" for the dcl-ds and end-ds lines so
you can keep track of when your data is nested inside something else, etc.
enddo;
QrnDiCloseResultVar(v);
This would allow the parser to make better decisions in many cases.
For example, if an element is supposed to get a default value from the
parser, should it use a *blank or 0 or d'0001-01-01' No way to know
what to pass right now because the parser knows nothing about the
variable it's mapping into.
Or suppose the parser wants to implement a feature similar to the
"countprefix" feature where there is another field with a prefix tht
corresponds to the first field. Since we have no way to see what is in
the data structure, we can't evaluate whether there's a field with a
prefix -- meaning the parser is limited in the decisions it can make
with what to do with the data.
I don't agree with Jon's assessment that DATA-INTO couldn't do this.
After all, it knows all about the resulting variable at compile-time...
there's no reason it couldn't provide this info to the parser somehow.
Same with the generator in DATA-GEN.
-SK
On 9/15/23 7:38 AM, Suren K wrote:
Hi Jon,wrote:
I am planning to send some additional parameters in the Parser parameter
section and retrieve the list of fields in the parser parameter that have
the truncation issue.
Regards,
Suren
On Thu, Sep 14, 2023 at 6:44 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx>
string
The problem you face is that RPG does not supply that information to the
parser - nor could it really. The parser gives RPG a name and the
report itassociated with it. RPG then stores it in the DS after conversion if
needed. Even if you could do it (more in a minute) how would you
checkingto your RPG program?
I think a better option is to make all the fields varchar of a length
longer than they could be. Then process the data into the real DS
thelength etc as you do so.
The only way I can think of to have the parser validate it is to pass
lengthsparser an extra parm containing an array of all the field names and
toof the real DS and use that to validate the length before returning it
ofRPG.
Jon P
On Sep 14, 2023, at 4:20 PM, Suren K <suren7437@xxxxxxxxx> wrote:
Hi All,
I am planning to add logic in the DATA-INTO Parser Program, before
populating the value into Data Structure, I need to verify the length
%parser('mpParser':userParm);the fields to validate whether any truncation is happening.
For example
dcl-ds Ds_Input;
name char(5);
number zoned(4:0);
end-ds;
data = '{"name": "David John","number": 123}';
data-into Ds_Input %data(data:dataOption)
but
In the above example, the name attribute is the character of length 5
relatedthe value will be 10 characters. I want to validate this in the Parserattribute
Program.
Is it possible to get the attribute inside the parser program like the
attribute of the field "name" is a character of length 5 and the
of a field "number" is numeric of length 4 with 0 decimal places whenrelated questions.
parsing field by field?
Regards,
Suren
--
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@xxxxxxxxxxxxxxxxxxxx for any subscription
--
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@xxxxxxxxxxxxxxxxxxxx for any subscription
--questions.
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@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
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@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
As an Amazon Associate we earn from qualifying purchases.
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.