Re: Reg: Adding additional changes in YAJLINTO Parser

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