Multi-level Data Structures

[James-S]

In profound.js there is the function pjs.toObject(...) to convert a json object to a data structure that can be passed to an RPG program.

Say I have a multi-level data structure like the one below.

Code: Select all

dcl-ds $partDetailTx qualified template;
         tracking_id   uns(10);
         count	    uns(5);

         dcl-ds detailDS dim(1600);
           id                   uns(10);
           quantity   zoned(9:2);
         end-ds;

       end-ds;                         

Example json:

Code: Select all

{
    "partDetailTx": {
        "tracking_id": 12345,
        "count": 2,
        "detailDS": [
            {
                "id" : 1,
                "quantity": 12.34
            },
            {
                "id" : 2,
                "quantity": 23.45
            }
        ]
    }
}

What would the pjs.define object definition look like?

I was looking at this document which has a good example but it is only a single level qualified data structure.

https://docs.profoundlogic.com/download ... cation/pdf

[Scott Klement]

In profound.js there is the function pjs.toObject(...) to convert a json object to a data structure that can be passed to an RPG program.

That's actually the opposite of what it does. pjs.toObject() converts a strongly-typed data structure to an object. (Thus "toObject" because it converts to an object.)

Say I have a multi-level data structure like the one below.

Code: Select all

       dcl-ds $partDetailTx qualified template;
         tracking_id   uns(10);
         count	    uns(5);

         dcl-ds detailDS dim(1600);
           id                   uns(10);
           quantity   zoned(9:2);
         end-ds;

       end-ds;                         

What would the pjs.define object definition look like?

I wouldn't declare a data structure like this in Node.js unless absolutely necessary because you need to call an RPG program that accepts it as a parameter. If you just need it to create a JSON object, it'd be much more elegant to use native JavaScript methods rather than a strongly-typed data structure.

So.. assuming you wanted to call an RPG with this, you'd code it this way:

Code: Select all

  pjs.define("detailDS_t", { type: 'data structure', qualified: true, template: true, elements: {
    "id": { type: 'unsigned integer', length: 10, decimals: 0 },
    "quantity": { type: 'decimal', length: 9, decimals: 2 }
  }});

  pjs.define("partDetailTx", { type: 'data structure', qualified: true, elements: {
    "tracking_id": { type: 'unsigned integer', length: 10, decimals: 0 },
    "count": { type: 'unsigned integer', length: 5, decimals: 0 },
    "detailDS": { type: 'data structure', likeDS: 'detailDS_t', dim: 1600 }
  }});

  pjs.call("the-rpg-program", partDetailTx);

  var obj = pjs.toObject(partDetailTx);

Code: Select all

{
    "partDetailTx": {
        "tracking_id": 12345,
        "count": 2,
        "detailDS": [
            {
                "id" : 1,
                "quantity": 12.34
            },
            {
                "id" : 2,
                "quantity": 23.45
            }
        ]
    }
}

Hmmm.. this doesn't match the RPG definition that you gave!!

Every time you have a { in JSON, that must match a DCL-DS in RPG. Every time you have a } in JSON, it matches an END-DS;
So when your document starts like this:

Code: Select all

{
   "partDetailTx": {

That's not just one data structure named partDetailTx!! That's two. So the RPG definition would actually look like this (with comments showing how it matches up to the JSON:

Code: Select all

                                                   // matches this JSON object:
       dcl-ds myDS qualified;                      //  {
      
         dcl-ds partDetailTx;                      //    "partDetailTx": {
           tracking_id uns(10);                    //      "tracking_id": number,
           count       uns(5);                     //      "count": number,

           dcl-ds detailDS dim(1600);              //      "detailDS": [{
             id                   uns(10);         //          "id": number,
             quantity   zoned(9:2);                //          "quantity": number
           end-ds;                                 //       }]

         end-ds;                                   //    }

       end-ds;                                     //  }

That extra level where you have { "partDetailTx": { really doesn't do anything useful, though... so I don't understand why it's there. I guess you feel that it's important to see the word "partDetailTx" in the document? Since the outermost level of a document never has a name you have to add this extra level to be able to put the name in there.

The reason the outermost part of a JSON document never has a name is because you're going to assign it to a JavaScript variable. JavaScript variables have their own name, so you end up with an extra, pointless, name.

For example, imagine assigning your JSON example to a JavaScript variable:

Code: Select all

var partDetailTx = {
  "partDetailTx": {
    "tracking_id": 12345,
    ... etc ...
  }
}

if (partDetailTx.partDetailTx.tracking_id == 12345) {
  //code
}

Yuck! Why add that extra level? I strongly discourage you from doing that... instead, do what you did in your original RPG program where you didn't have "partDetailTx" in the JSON, but rather used it as the outermost (unnamed) element.

Code: Select all

var partDetailTx = {
  "tracking_id": 12345,
}

if (partDetailTx.tracking_id == 12345) {
  //code
}

Sorry... that was a detour from your question... but I wanted to make sure you understood that having the "partDetailTx": { in the document wasn't a good idea.

Oh... also your RPG program had a dollar-sign ($) character in the name of the DS ($partDetailTx). I also removed it from my JSON version because working with variables that begin with a dollar-sign in JavaScript is possible, but very ugly. I strongly recommend not using them. (I also will never use them in my RPG code since the source code wouldn't work in other countries, for example, the dollar sign would cause problems in Germany or the UK -- using $, # or @ to start a variable name in RPG is a very bad practice.)

Ok... you get the idea. I'll get off of the soap box now.

[James-S]

Hey Scott.

One thing I like about your responses is you are going to be honest and tell it like you see it. No two developers will ever see everything the same way but we can learn from each other which is why forums like this work.

There's a couple of things I should clarify.

• I got pjs.toObj and pjs.copyToDS confused in my post. I am learning the pjs framework and just got my function names backwards. My bad!

• I have production implementation using YAJL and I found this manner of using the partDetailTx level works well with using data-into and YAJL in populating a data structure. I really wasn't thinking of how it would be used in javascript. But I do see what you mean and will be mindful of that in javascript coding. I see that is overkill when assigning it to a javascript variable object. As such probably can be also dropped when passed data in parameters and not as the json itself which would need to be parsed by YAJL. Thanks for pointing that out.

• I should have left out the $ in the data structure name. That was copied from a template in an RPG copybook. We use $ as a prefix for templates and then create the actual program data structure doing a likeDS to the template. To that point, I am confused why characters like $,@,# are bad practice. During my entire 30 year programming career I have seen various version of using those character for standards in various RPG shops. My current shop we use $ to define tempates, @ to define global variables and # to define constants. Guess we don't expect our source to go outside of the US. Would like to know more about your insight into not using these. Maybe be good to take this outside this forum. :)

[Scott Klement]

• I should have left out the $ in the data structure name. That was copied from a template in an RPG copybook. We use $ as a prefix for templates and then create the actual program data structure doing a likeDS to the template. To that point, I am confused why characters like $,@,# are bad practice. During my entire 30 year programming career I have seen various version of using those character for standards in various RPG shops. My current shop we use $ to define tempates, @ to define global variables and # to define constants. Guess we don't expect our source to go outside of the US. Would like to know more about your insight into not using these. Maybe be good to take this outside this forum. :)

I honestly don't know why it works the way it does... but, since I've written a lot of articles, presentations, webinars, open source software, etc, it's commonplace for my code to be used by people in other countries.

For example, set your job CCSID to 1026 (Turkey) and create a SRCPF with CCSID(1026), then write a program with # in a variable name and try to compile it -- it simply won't work.

I'm old and worn out. I've spent too many months of my life trying to fix code (sometimes "old code", sometimes stuff that isn't even that old) that other developers wrote because we now need to make it work for people in a different country. You can literally spend MONTHS trying to fix this stuff that literally would've worked as-is if they didn't use variable names with these characters in them.

It just makes me feel old and grouchy when I see it.

[James-S]

Totally understand. I admit I never wrote code to be used "internationally" and haven't ventured outside the default CCSID so I as many others may not even be aware of this variable naming limitation. Will have to store that away for future use if I ever do need to be cognizant writing source to be internationally. Thanks for mentioning it.

It just makes me feel old and grouchy when I see it.

As for old and grouchy, I see us as the Alan Parson's song, "Old and Wise". :)