Problem putting packed fields in a ds from a json in standard in

[allthom]

Hello' everybody, I'm creating a POC for one of our application, working with the DIY web service provider. In our scenario we receive a JSON representing a row (or record of a table) had to write/insert into the table and call another program to work on it. A very simple scenario but i must be missing something because i can't make it work.
The data from standardin is putted right into a ds representing the db table row. It has mainly character and numeric packed fields.
This is my ds:

Code: Select all

dcl-ds t_socie Qualified Inz;
IDRECO  paked(11:0) 
STATUS  char(1)
CODICE  packed(6:0)
SIGLAD  char(6)
DENOMI char(25)
ATTIDL  char(2)
CODISC char(6)
FLAGEL char(1)
DATELG packed(2:0)
DATELM packed(2:0)
DATELA packed(4:0)
DATELB date datfmt(*ISO)
end-ds;

Then here is the json i am using for a simple test

Code: Select all

{
"IDRECO": 0,
"STATUS": " ",
"CODICE": 960000,
"SIGLAD": "ATP",
"DENOMI": "MODEST MOUSE",
"ATTIDL": "DL",
"CODISC": "123456"
"FLAGEL": " ",
"DATELG": 28,
"DATELM": 04,
"DATELA": 2023, 
"DATELB": '0001-01-01'
}

After running in my pgm

Code: Select all

data-into t_socie %DATA('*STDIN' : 'case=convert allowmissing=yes')
                      %PARSER('YAJLINTO');

in my debug i see

Code: Select all

EVAL t_socie                                
 T_SOCIE.IDRECO = 00000000000.               
 T_SOCIE.STATUS = ' '                        
 T_SOCIE.CODICE = 960000.                    
 T_SOCIE.SIGLAD = 'ATP   '                   
 T_SOCIE.DENOMI = 'MODEST MOUSE             '
 T_SOCIE.ATTIDL = 'DL'                       
 T_SOCIE.CODISC = '123456'                   
 T_SOCIE.FLAGEL = ' '                        
 T_SOCIE.DATELG = 00.                        
 T_SOCIE.DATELM = 00.                        
 T_SOCIE.DATELA = 0000.                      
 T_SOCIE.DATELB = '0001-01-01'  

why DATELG, DATELM DATELA have not the right values? In my ctl-opt instrucions i have defined decedit('0,') may this be the problem? Can someone point me to the solution? I feel i must be missing something very stupid.
TIA everybody.

[jonboy49]

I found two problems when I ran a subset of your example.

First "DATELM":04 is flagged as invalid json by YAJLINTO and JSONLINT.COM removing the leading zero cures that issue.

The second, and I have not seen this issue before, is that there appears to be a problem with the fields being packed. Change them to zoned or integer and they work fine. There is another packed field in the DS that works fine so ... Maybe Scott has some ideas.

I also noticed that your definition for DATELB is wrong and for me (as expected) would not compile. I should have been DATELB date(*ISO);

[allthom]

Thanks jonboy49,
DATELB's definition is wrong on the code here but in my pgm is right, defined as you said.
In my json test case there are a couple of error, a missing comma after codfisc value, and missing double quotes for DATELB value.
So the correct json to run the test should be:

Code: Select all

{
"IDRECO": 0,
"STATUS": " ",
"CODICE": 960001,
"SIGLAD": "ATP",
"DENOMI": "MODEST MOUSE 2",
"ATTIDL": "DL",
"CODISC": "123456",
"FLAGEL": " ",
"DATELG": 28,
"DATELM": 04,
"DATELA": 2023, 
"DATELB": "0001-01-01"
}

Anyway I've noticed a couple of things, as you said packed numbers staritng with zeros, i.e. 04 are not correctly interpreted by YAJLINTO, that's the result in debug:

Code: Select all

EVAL t_socie                                
T_SOCIE.IDRECO = 00000000000.               
T_SOCIE.STATUS = ' '                        
T_SOCIE.CODICE = 960001.                    
T_SOCIE.SIGLAD = 'ATP   '                   
T_SOCIE.DENOMI = 'MODEST MOUSE 2           '
T_SOCIE.ATTIDL = 'DL'                       
T_SOCIE.CODISC = '123456'                   
T_SOCIE.FLAGEL = ' '                        
T_SOCIE.DATELG = 28.                        
T_SOCIE.DATELM = 00.                        
T_SOCIE.DATELA = 2023.                      
T_SOCIE.DATELB = '2023-04-13'               

as you may see the value of DATELB is the current date instead of the *loval value in the JSON

If i use this json

Code: Select all

{
"IDRECO": 0,
"STATUS": " ",
"CODICE": 960001,
"SIGLAD": "ATP",
"DENOMI": "MODEST MOUSE 2",
"ATTIDL": "DL",
"CODISC": "123456",
"FLAGEL": " ",
"DATELG": 28,
"DATELM": 4,
"DATELA": 2023, 
"DATELB": "0001-01-01"
}

everything works fine

Code: Select all

EVAL t_socie                                
T_SOCIE.IDRECO = 00000000000.               
T_SOCIE.STATUS = ' '                        
T_SOCIE.CODICE = 960001.                    
T_SOCIE.SIGLAD = 'ATP   '                   
T_SOCIE.DENOMI = 'MODEST MOUSE 2           '
T_SOCIE.ATTIDL = 'DL'                       
T_SOCIE.CODISC = '123456'                   
T_SOCIE.FLAGEL = ' '                        
T_SOCIE.DATELG = 28.                        
T_SOCIE.DATELM = 04.                        
T_SOCIE.DATELA = 2023.                      
T_SOCIE.DATELB = '0001-01-01'

Maybe Scott could explain this strange behaviour.

[jonboy49]

As I noted earlier - leading zeros are not valid in JSON. See here (among many other web pages) https://stackoverflow.com/questions/273 ... ading-zero

Apparently some parsers allow it as a non-standard feature. I don't know enough about YAJL to know. Scott probably does.

I have no idea where the current date is coming from.

[Scott Klement]

The JSON standard does not allow for a number to start with zero, except for the number zero itelf. See here:
https://www.json.org/json-en.html

If other JSON parsers allow the leading zero, then they are allowing non-standard values.

Whether a field is packed or not is not, as far as I can tell, germaine to any of the problems reported here. The same behavior should exist regardless of whether it is packed, zoned, integer, floating point, etc... in fact, YAJL does not know how your RPG fields are defined, that is handled entirely within RPG.

Same with the date field. Since there is no such thing as a date field in JSON, it is just a character string. YAJL is reporting the character string to RPG -- it is entirely up to RPG how it maps it into the RPG variable. If something weird is happening with the current date appearing in the field, this would be a bug in the RPG compiler because, again, YAJL has no concept of how your fields are defined. It is simply passing a character string to DATA-INTO.