Re: Reg: Adding additional changes in YAJLINTO Parser

Hi Scott,

Thanks for the reply.

Yes, I am fully aware of the Licensing part. I am modifying and using it in
a different name, to easy understanding i mentioned YAJLINTO.

I will use userparm as per my requirement.

Thanks for your response once again. I really appreciate it!!!

Regards,
Surender K

On Fri, Aug 2, 2019 at 12:59 PM Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
wrote:

Suren,

You're welcome to create your own software that's derived from YAJLINTO
if you wish. But, please be aware that your modified version with your
own application-specific customizations is no longer 'YAJLINTO', instead
it is a derivation that is your own code to understand and maintain.
(Don't expect me to provide support for it!)

Please use a different name. (SURENINTO?) That way it'll be clear that
you aren't using the regular YAJLINTO program, but your own code that is
a derivation. Also, please see the license agreement at the top of
YAJLINTO for details about how you're allowed to use the code.

With regards to the %PARSER options parameter. The way IBM implemented
this is really cumbersome to work with. When the caller specifies it as
a literal directly on the %PARSER function, IBM provides it as a
null-terminated string -- and that works great. But, when its provided
as a variable, the parser only receives a pointer to that variable,
there is no other information given, not even the length of the data.
I think IBM assumed that the person writing the parser would be the same
as the person calling it, so would know what data was passed -- but, in
my case, anyone can call my parser, and I have no idea what type of
variable they'll pass.

My workaround can be found in the "handleUserParm" subprocedure. It
tries to determine whether the caller provided a VARYING or VARYING(4)
string by looking for the '{' character in the string. If the '{'
character is in the 3rd byte, it thinks its VARYING, if its in the 5th
byte, it thinks its VARYING(4), and if its in the very first byte, it
thinks it's a flat CHAR field. If it's VARYING, that's great because at
least we'll have the length passed to us. If it's a flat CHAR field,
we have no way of knowing how long the CHAR field is, so we try to
figure it out by scanning for the closing '}' character. (I really hate
flat CHAR fields, and I wish IBM would remove them from RPG! Everything
should be VARYING like it is in almost every other programming language
on earth!) If the caller omits the closing '}' character, the results
are unpredictable since we have no way of knowing the actual field length.

To mitigate that somewhat, I limit the size of the field to 1000
characters. YAJLINTO will probably never need more than that for the
parser options. But, if you do in your customized version, you'll have
to modify the code accordingly.

-SK

On 8/2/2019 11:24 AM, Suren K wrote:

Hi Scott and Everyone,

I am adding additional changes in YAJLINTO Parser for adding two generic
validations (Data Type Validations and Data Truncation Validations). By
adding this i don't want to repeat the same logic in all the programs

where

i am using DATA-INTO for parsing JSON Document.

The Logic which i am using are
1) I have added one more parser option "File_Name" = EDS Name for the

Data

Structure which i am using for DATA-INTO.
2) I am passing the Parser option in a Work Variable (Length i am setting
as example 10000 Character) Example as below
Wrk_PsrOpt = '{ "document_name": "json", ' +
' "value_true": "1", ' +
' "value_false": "0", ' +
' "file_name": "CFEIAUP06" }';

data-into(E) DS01_DtaStr %DATA(Json_Var:Wrk_Opt)
%PARSER('YAJLINTO':Wrk_PsrOpt);
3) I am getting the EDS File name inside the Parser Program YAJLINTO and
fetching the File Field attributes. Based on the Json Field name and

Value

parsed inside the YAJLINTO (In routines do_string, do_number, etc...) I

am

doing the required validations and populated the Warning Messages and

Error

Messages into an Array.
4) Before YAJLINTO Program Exit, i am populating the Message Array data
into the Address of Parser Parameter (PARM.USERPARM which has the address
of the Parser Options)
5) Once the data-into line executed from my main program, i am getting

the

populated Error and Warning Messages details in the Wrk_PsrOpt Field.

I have below clarifications
1) I am using the Parser Option field as a communication area for sending
some details from the Parser program to the Main program. Is this the

right

way or we have any other way to communicate?
2) What is the maximum field length i can pass as a Parser Option? Since
Data-Into is sending the address as a parameter so i am thinking there

will

not be any limit (We can send up to Maximum character field length)

Could you please let me know your suggestions on this one?

Regards,
Surender K

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