YumaWorks

Yangdump generates SIL code stubs which are basically the skeleton of the SIL code. These auto-generated SIL codes fill the non-configurable nodes with a "0" or an empty string. These might or might not satisfy the module and result in validation error while yangcli is validating the rpc-reply it received.

These auto-generated SIL or SIL-SA code stubs should be filled and completed as required and demanded by the module.

Consider the below module:

module sample-mod {
  namespace "http://www.yumaworks.com/ns/sample-mod";
  prefix sam-mod;

  revision "2019-04-22";

  container container1 {
    list list1 {
      key "name";
      leaf name {
        type string;
        description
          "name of the list";
      }
      leaf number {
        config false;
        type uint8 {
            range "1..255";
        }
        description
          "number to the list";
      }
    }
  }
}

When SIL code is generated for the above module with 

make_sil_dir_pro --split sample-mod

The leaf "number" will take the value 0 as below:

/********************************************************************
* FUNCTION u_sample_mod_container1_list1_number_get
*
* Get database object callback for leaf number
* Path: /container1/list1/number
* Fill in 'dstval' contents
*
* INPUTS:
*     see ncx/getcb.h for details (getcb_fn_t)
*
* RETURNS:
*     error status
********************************************************************/
status_t u_sample_mod_container1_list1_number_get (
    val_value_t *dstval,
    const xmlChar *k_container1_list1_name)
{
    status_t res = NO_ERR;
    uint8 v_number;

    if (LOGDEBUG) {
        log_debug("\nEnter u_sample_mod_container1_list1_number_get callback");
    }


    /* set the v_number var here, change zero */
    v_number = 0;
    VAL_L_UINT8(dstval) = v_number;

    return res;

} /* u_sample_mod_container1_list1_number_get */

When we do a simple edit and get operation on this module without editing the generated SIL code stub, the value "0" for the node "number" is not accepted by the yangcli or yp-shell when displaying the output and fails with an error like:

mgr_rpc: got invalid reply on session 1 (value not in range)

Hence it should be carefully changed and validated in the SIL code to make sure it respects the range mentioned in the Yang module in this scenario or any other conditions mentioned in the module in general.