yangdump-pro CLI Reference

--defnames

The --defnames parameter causes the program output file to be named with the default name for the format, based on the input module name and revision date. Refer to the HTML Translation section for details on specific file formats for HTML output.

If the --output parameter is present and represents an existing directory, then the default filename will be created in that directory, instead of the current directory.

This parameter is ignored if the --format parameter is missing.

leaf defnames {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --defnames=true --subtree=~/workdir/ --format=html

--dependencies

The --dependencies parameter causes information to be reported for the symbols that this [sub]module imports from other modules.

The following information is reported for each dependency:

module name
revision date

Example report for module 'yangdump-pro':

dependencies:

import ncx 2009-06-12
import ncx-app-common 2009-04-10
import ncxtypes 2008-07-20

leaf dependencies {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --dependencies --module=test4

--doxygen-headers

The --doxygen-headers parameter controls whether doxygen format headers will be used.

If 'true' then doxygen comments will be generated in the yumapro-pro program for C and H file generation.
If 'false' then the older existing header format will be generated in the yumapro-pro program for C and H file generation.

leaf doxygen-headers {
    type boolean;
    default true;
  }

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro --doxygen-headers=false

--exports

The --exports parameter causes information to be reported for the symbols that this [sub]module exports to other modules.

The exports for the entire module are printed, unless the specified input file is a YANG submodule. In that case, just the exports in the submodule are reported.

It includes the following information, generated in this order:

[sub]module name
version
source filespec
namespace (module only)
prefix (module only)
belongs-to (submodule only)
typedefs
groupings
objects
RPC operations
notifications
extensions
features

leaf exports {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --exports --module=test3

--feature-code-default

The --feature-code-default parameter controls how yangdump-pro will generate C code for YANG features by default.

If dynamic, then by default, features can be loaded at run-time, and objects with if-feature statements will be available in case the feature is enabled.
If static, then by default, features are set at compile-time, and any disabled objects will be removed at load-time.
If a --feature-dynamic or --feature-static parameter is present for a specific feature, then this parameter will be ignored for that feature.

leaf feature-code-default {
  type enumeration {
    enum static {
    }
    enum dynamic {
    }
  }
  default dynamic;
}

Syntax	enum (dynamic or static)
Default:	dynamic
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --format=c --feature-code-default=static --module=test

--feature-dynamic

The --feature-dynamic parameter controls how yangdump-pro will generate dynamic code for a specific feature. This parameter is a formatted string containing a module name, followed by a colon ':', followed by a feature name:

test:feature1

It is an error if a --feature-static and this parameter specify the same feature.

Parameters for unknown features will be ignored.

leaf-list feature-dynamic {
  type yt:FeatureSpec;
}

Syntax	formatted string (module:feature)
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	yangdump-pro
Example:	yangdump-pro --format=c --feature-dynamic=test:feature1 --module=test

--feature-static

The --feature-static parameter controls how yangdump-pro will generate static code for a specific feature.

This parameter is a formatted string containing a module name, followed by a colon ':', followed by a feature name, e.g.,

test:feature1

It is an error if a --feature-dynamic and this parameter specify the same feature.

Parameters for unknown features will be ignored.

leaf-list feature-dynamic {
  type yt:FeatureSpec;
}

Syntax	formatted string (module:feature)
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	yangdump-pro
Example:	yangdump-pro --format=c --feature-static=test:feature1 --module=test

--force-prefix

The --force-prefix parameter specifies the prefix to use for short name generation.

If the --short-names parameter is 'true' then this object can be used to force a specific prefix value instead of the module prefix, when generating instrumentation code.

This object should only be used if the module prefix is known to cause a naming conflict with existing code.

This object cannot be used if the --sil-bundle parameter is also used, and --short-names=true.

leaf force-prefix {
  type yt:NcxName;
}

Syntax	identifier string
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-sdk --format=c --force-prefix=acme --module=test4

--format

The --format parameter controls the type of yangdump-pro conversion desired, if any.

YumaPro SIL developers should refer to the make_sil_dir_pro or other script to generate SIL code instead of using the yangdump-pro command directly for code generation formats (c, h, uc, uh, yc, yh).

If this parameter is missing, then no translation will be done, but the module will be validated, and any requested reports will be generated.

The following values are supported:

yin
- Generate standard YIN format (XML instance document)
xsd
- XSD 1.0 translation .
- Data model XSD can be integrated with the with the NETCONF protocol XSD in RFC 4741.
html
- XHTML 1.0 translation.
yang
- Canonical YANG translation .
copy
- Copy with a new name, in canonical module naming format.
sql
- TBD: Generate a module specific SQL template
- This option is not implemented and not supported.
sqldb
- Generate module specific SQL data for the netconfcentral.sql template.
h
- Generate a module specific netconfd-pro agent instrumentation combined SIL H file.
c
- Generate a module specific netconfd-pro agent instrumentation combined SIL C file.
uh
- Generate a module specific netconfd-pro agent instrumentation User SIL H file.
uc
- Generate a module specific netconfd-pro agent instrumentation User SIL C file.
yh
- Generate a module specific netconfd-pro agent instrumentation YumaPro SIL H file.
yc
- Generate a module specific netconfd-pro agent instrumentation YumaPro SIL C file.
bh
- Generate a SIL bundle netconfd-pro agent instrumentation YumaPro SIL H file.
bc
- Generate a SIL bundle netconfd-pro agent instrumentation YumaPro SIL C file.

leaf format {
  type FormatType;
}

Syntax	enumeration (xsd, sql, sqldb, html, yang, copy, h, c, uc, uh, yc, yh))
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro test1 test2 --format=html --defnames=true --output=~/workdir

--html-div

The --html-div parameter controls whether yangdump-pro HTML translation will generate a single <div> element, or an entire HTML document.

If HTML translation is requested, then setting this parameter to 'true' will cause the output to be a single <div> element, instead of an entire HTML file. This parameter is ignored unless the --format=html parameter is used.

This parameter allows the HTML translation to be easily integrated within more complex WEB pages, but the proper CSS definitions need to be present for the HTML to render properly. It is suggested only HTML experts use this parameter.

The default filename extension will be '.div' instead of '.html' if this parameter is present. The contents will be well-formed XHTML 1.0, but without any namespace declarations.

leaf html-div {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --html-div=true --format=html --module=test

--html-toc

The --html-toc parameter controls how yangdump-pro HTML translation will generate a table of contents for the HTML document.

If HTML translation is requested, then this parameter will cause the output to contain a bullet list TOC, a drop-down menu TOC, or none.

This option has no effect unless the --format=html parameter is also present.

The following values are supported:

none
- No TOC is generated.
plain
- A plain list-based TOC is generated
menu
- A suckerfish (Javascript) drop-down menu will be generated.
- This is the default option.

leaf html-toc {
  type TocType;
}

Syntax	enumeration (none, plain, menu)
Default:	menu
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --html-toc=plain --format=html --module=test

--identifiers

The --identifiers parameter causes information to be object identifier strings to be reported for the object, RPC operation, and notification definitions within the input module(s).

Each accessible object node is listed once, including all child nodes. Notifications and RPC methods are considered top-level objects, and have object identifiers as well as configuration and state data.

The following information is reported for each identifier:

object type (e.g., leaf, container, rpc)
absolute XPath expression for the object

Example report for module yuma-mysession.yang:

identifiers:

rpc /get-my-session
container /get-my-session/output
leaf /get-my-session/output/indent
leaf /get-my-session/output/linesize
leaf /get-my-session/output/with-defaults
container /get-my-session/input
rpc /set-my-session
container /set-my-session/input
leaf /set-my-session/input/indent
leaf /set-my-session/input/linesize
leaf /set-my-session/input/with-defaults
container /set-my-session/output

leaf identifiers {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --identifiers --module=yuma-mysession

--lang-errors

The --lang-errors parameter causes the yangdump-pro program to list all the error and warning numbers, and the default message for each one. This is done in the format expected by the errmsg-tr.py error message translator program.

After this is done, the yangdump-pro program will exit.

Example output:

400@session dropped
401@media type not in range
402@an appropriate representation could not be found
403@data is not in a format acceptable for processing
404@unknown query parameter
405@missing Accept header
406@password is too short
407@missing input data
408@value disabled by if-feature-stmt
409@when-stmt not allowed on key leaf
410@if-feature-stmt not allowed on key leaf
411@invalid XML response would be returned
412@JSON encoding not yet supported
413@missing data definition statement
414@default value conditional on if-feature
415@invalid escape sequence in double-quoted string
416@invalid status for child node
417@configuration template not found

leaf lang-errors {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --lang-errors

--modversion

The --modversion parameter causes the module name and revision date to be displayed for each module specified in the input.

Example output for module 'test':

modversion:

module test 2009-06-10

leaf modversion {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --modversion --module=test

--objview

The --objview parameter specifies how objects will be generated during translation, for HTML and canonical YANG file translations.

The enumeration values are:

raw
- output includes augment and uses clauses, not the expanded results of those clauses.
cooked
- output does not include augment or uses clauses, just the objects generated from those clauses.

The default mode is the 'raw' view.

leaf objview {
  type ObjViewType;
}

Syntax	enumeration (raw, cooked)
Default:	raw
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --objview=cooked --module=test --format=html

--quiet-mode

The --quiet-mode parameter specifies that quiet mode reporting should be done. In this mode, the module summary line will not be printed unless there are errors or warnings for the module. This parameter only works with the --module parameter, not the --subtree parameter.

Without this parameter:

user1$ yangdump-pro --module=test

*** /home/andy/swdev/ypwork/netconf/modules/test/pass/test.yang
*** 0 Errors, 0 Warnings

user1$

With this parameter:

user1$ yangdump-pro --module=test  --quiet-mode

user1$

leaf quiet-mode {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro --quiet-mode --subtree=test

--short-names

The --short-names parameter specifies if short names of long names will be used in SIL or SIL-SA code generation.

If 'true', generate instrumentation code using short names whenever possible. The module prefix and the node name will be used. A numeric qualifier will be appended to the name if the short name would cause a duplicate symbol to be generated. The 'force-prefix' value will be use for the prefix if that parameter is present.

If 'false', then generate instrumentation code using long names which encode the module name and the entire path to the object into the name.

Refer to the Short Names for SIL and SIL-SA Code Generation section for more details.

leaf short-names {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro --short-names=false --module=test --format=yc

--show-errors

The --show-errors parameter causes the yangdump-pro program to list all the error and warning numbers, and the default message for each one.

The 3 digit number, followed by the message string, will be printed 1 per line.

After this is done, the yangdump-pro program will exit.

This parameter can be combined with the --help parameter. The --version parameter has no effect if this parameter is present. The program version string will be printed in both cases.

The NETCONF error-tag values are used directly when no other error number is appropriate. These error numbers are as follows:

   resource in use
   invalid value
   too big
   missing attribute
   bad attribute
   unknown attribute
   missing element
   bad element
   unknown element
   unknown namespace
   access denied
   lock denied
   resource denied
   rollback failed
   data exists
   data missing
   operation not supported
   operation failed
   partial operation

leaf show-errors {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --show-errors

--sil-bundle

The --sil-bundle parameter specifies the name of the SIL bundle to create. It is used with the --format parameter to generate specific SIL C or H files. The --module parameter is used to specify the YANG modules that will be included in the SIL bundle.

The parameter specifies the name of the SIL bundle to create. It is used to create SIL code stubs for a bundle of YANG modules.

All the specified modules will be loaded into memory. Then the SIL code stubs will be generated according to the given parameters. Any external augment-stmt data will be expanded at this point, so the SIL code will be generated for the fully augmented version.

leaf sil-bundle {
  type yt:NcxName;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	no maximum
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro --format=yc --sil-bundle=test --module=test1 --module=test2 --module=test3

--sil-edit1

The --sil-edit1 parameter is used to control code generation. If present, then the deprecated first generation 'edit' functions will be generated for SIL or SIL-SA modes instead of current 2nd generation 'edit' functions, if code generation is being requested. Ignored otherwise. Refer to the EDIT1 Callback section for more details.

Note

The EDIT1 callbacks are now deprecated. A warning will be generated if this parameter is used for code generation.

leaf sil-edit1 {
  type empty;
  status deprecated;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro --format=yc --sil-edit1 --module=test1

--sil-edit2

The --sil-edit2 parameter specifies that the second generation SIL or SIL-SA edit callbacks should be generated instead of the first generation callbacks. The new callbacks are optimized so the terminal nodes (leaf, leaf-list-, anyxml) are handled by a parent callback (for container, list, or choice). Refer to the EDIT2 Callback section for mode details.

The EDIT2 callbacks are now the default. This parameter is no longer needed.

leaf sil-edit2 {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro --format=yc --sil-edit2 --module=test1

--sil-edit3

The --sil-edit3 parameter specifies that the third generation SIL or SIL-SA edit callbacks should be generated instead of the other generation callbacks. The new callbacks are optimized so the terminal nodes (leaf, leaf-list, anyxml) are handled by a parent callback (for container, list, or choice). Refer to the EDIT3 Callback section for mode details.

The EDIT3 callbacks are not the default. This parameter must be specified to enable EDIT3 callbacks.

leaf sil-edit3 {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro --format=yc --sil-edit3 --module=test1

--sil-get1

The --sil-get1 parameter is used to control code generation. If present, then the deprecated first generation 'get' functions will be generated for SIL or SIL-SA modes instead of current 2nd generation 'get' functions, if code generation is being requested. Ignored otherwise.

Note

The GET1 callbacks are now deprecated. A warning will be generated if this parameter is used for code generation.

leaf sil-get1 {
  type empty;
  status deprecated;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro --format=yc --sil-get1 --module=test1

--sil-get2

The --sil-get2 parameter specifies that the second generation SIL or SIL-SA get callbacks should be generated instead of the first generation callbacks. The new callbacks are optimized so the terminal nodes (leaf, leaf-list-, anyxml) are handled by a parent callback (for container, list, or choice). Refer to the GET2 Callback section for more details.

Note

The GET2 callbacks are now the default. This parameter is no longer needed.

leaf sil-get2 {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro --format=yc --sil-get2 --module=test1

--sil-include

The --sil-include parameter specifies the name of a file to use in a C “#include” statement. These statements will be generated in the C files only, and in the order they are specified.

Specifies the name of an include file to inject into C files when the conversion format is equal to 'c' or 'yc'. An #include statement will be generated for each instance of this parameter, in the order these parameters are given.

The #include statements will be generated after the system <include> statement and general YumaPro include statements, but before the YANG module specific include statements.

leaf-list sil-include {
  ordered-by user;
  type string;
}

Syntax	string
Default:	none
Min Allowed:	0
Max Allowed:	no maximum
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro --format=yc --sil-include=system1.h --sil-include=system2.h --module=test

--sil-nmda

The --sil-nmda parameter specifies that NMDA specific SIL or SIL-SA C code should be generated.

If present, then the 2nd generation NMDA 'get' functions will be generated for SIL or SIL-SA modes, if code generation is being requested. Ignored otherwise.

The GET2 callbacks will be generated with extra NMDA specific code for config=true data nodes.

It is an error if this parameter is selected but --sil-get2 is not selected.

The extra code generated is used to support the <get-data> operation. There will be GET2 callbacks generated for configuration data nodes, along with corresponding register and unregister code.

There are 2 new parameters within the GET2 control block passed to the GET2 callback function:

datastore: identifies the NMDA datastore to retrieve data from.
with_origin: flag indicating that the NMDA “origin” property should be set for the data nodes returned by the GET2 callbacks

leaf sil-nmda {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro --format=yc --sil-get2 --sil-nmda --module=test

--sil-sa

The --sil-sa parameter specifies that the server callback code for a subagent (SIL-SA) should be generated instead of code for running in the master agent (SIL).

leaf sil-sa {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro yangdump-sdk
Example:	yangdump-pro--format=yc --sil-get2 --sil-sa --module=test1

--simurls

The --simurls parameter specifies how URL strings are generated for HTML links.

If HTML translation is requested, then setting this parameter to 'true' will cause the format of URLs within links to be generated in simplified form, for WEB development engines such as CherryPy, which support this format.

Normal URL format (false):
- http://example.com/mymodule.html?parm1=foo&parm2=bar#frag
Simplified URL format (true):
- http://example.com/mymodule/foo/bar#frag

leaf simurls {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --simurls=true --format=html --module=test

--stats

The --stats parameter is used to request a YANG usage statistics report.

See the --totals parameter to control statistics totals reporting, when used with this parameter.

Statistics are not normally collected. This must be enabled by setting this parameter to a value other than 'none' (the default). Any other value will cause statistics to be collected and reported after each input module is validated.

The verbosity of the statistics report is controlled with this parameter. Each enumeration includes all the previous statistics (from lower enumerations), plus additional statistics. The following table describes the counters that are displayed at each minimum enumeration value.

Complexity score	brief	Numeric score characterizing the level of implementation complexity for the module. A higher number indicates a more complex module.
Total nodes	brief	The total number of object nodes (data, notification, rpc) in the module.
Extensions	basic	The number of extension statements.
Features	basic	The number of feature statements.
Groupings	basic	The number of exported groupings.
Typedefs	basic	The number of exported typedefs.
Deviations	basic	The number of deviation statements.
Top Data Nodes	basic	The number of top-level data nodes.
Config nodes	basic	The number of configurable nodes.
Non-config nodes	basic	The number of non-configurable nodes.
Mandatory nodes	advanced	The number of mandatory nodes.
Optional nodes	advanced	The number of optional nodes.
Notifications	advanced	The number of notification statements.
Rpcs	advanced	The number of rpc statements.
Rpc inputs	advanced	The number of RPC input statements.
Rpc outputs	advanced	The number of rpc output statements
Augments	advanced	The number of top-level augment statements within data nodes (not groupings).
Uses	advanced	The number of uses statements within data nodes (not groupings).
Choices	advanced	The number of choice statements.
Cases	advanced	The number of case statements. This includes implied cases which contain a single data node.
Anyxmls	advanced	The number of anyxml statements.
NP containers	advanced	The number of non-presence containers.
P containers	advanced	The number of presence containers.
Lists	advanced	The number of list statements.
Leaf-lists	advanced	The number of leaf-list statements.
Key leafs	advanced	The number of leaf statements which are defined within a list to be a key.
Plain leafs	advanced	The number of plain leaf statements.
Imports	all	The number of import statements.
Integral numbers	advanced	The number of leaf and leaf-list statements that used a numeric data type other than decimal64.
Decimal64s	advanced	The number of leaf and leaf-list statements that used the decimal64 data type.
Enumerations	advanced	The number of leaf and leaf-list statements that used the enumeration data type.
Bits	advanced	The number of leaf and leaf-list statements that used the bits data type.
Booleans	advanced	The number of leaf and leaf-list statements that used the boolean data type.
Emptys	advanced	The number of leaf and leaf-list statements that used the empty data type.
Strings	advanced	The number of leaf and leaf-list statements that used the string data type.
Binarys	advanced	The number of leaf and leaf-list statements that used the binary data type.
Instance Identifiers	advanced	The number of leaf and leaf-list statements that used the instance-identifier data type.
Leafrefs	advanced	The number of leaf and leaf-list statements that used the leafref data type.
Identityrefs	advanced	The number of leaf and leaf-list statements that used the identityref data type.
Unions	advanced	The number of leaf and leaf-list statements that used the union data type.

leaf stats {
  type enumeration {
     enum none {
     }
     enum brief {
     }
     enum basic {
     }
     enum advanced {
     }
     enum all {
     }
  }
  default "none";
}

Syntax	enumeration [none, brief, basic, advanced, all]
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --stats=advanced --module=test

--subtree

The --subtree parameter is a leaf-list of path specifications that may contain YANG files.

It must be a string value that represents a path specification of the directory subtree to use.

All of the YANG source modules contained in the specified directory sub-tree will be processed.

Note that symbolic links are not followed during the directory traversal. Only real directories will be searched and regular files will be checked as modules. Processing will continue to the next file if a module contains errors.

If this string begins with a '~' character, then a username is expected to follow or a directory separator character. If it begins with a '$' character, then an environment variable name is expected to follow.

If 'false', then only the top-level directory specified by this parameter will be searched for YANG files.

If 'true', then all the directories contained within the one specified by this parameter will also be searched for YANG files. The exceptions are:

any directory beginning with a dot character ('.'), such as '.svn'
any directory named 'CVS'

Examples:

~/some/path ==> <my-home-dir>/some/path
~fred/some/path ==> <fred-home-dir>/some/path
$workdir/some/path ==> <workdir-env-var>/some/path

leaf-list subtree {
    type yt:NcPathSpec;
}

Syntax	string: path specification
Default:	none
Min Allowed:	0
Max Allowed:	unlimited
Supported by:	yangdiff-pro yangdump-pro
Example:	yangdump-pro --format=html --subtree=~/testmods --subtree=./workdir --output=./yang-html-files

--totals

The --totals parameter is used with the --stats parameter to control how summary statistics are reported.

The --stats parameter must be set to a value other than 'none' for this parameter to have any effect. The value of this parameter will control which statistics are reported.
Normally, no summary is generated (default is 'none').
The 'summary' value will not have any effect unless there is more than one input module in the statistics collection.
The 'summary-only' value will cause the module statistics reports to be skipped, and only a summary of all the input modules will be displayed.

leaf totals {
   type enumeration {
      enum none {
      }
      enum summary {
      }
      enum summary-only {
      }
   }
   default "none";
}

Syntax	enumeration [none, summary, summary-only]
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --stats=basic --totals=summary-only --subtree=~/my-test-modules

--tree-identifiers

The --tree-identifiers parameter causes information to be object identifier name strings to be reported for the object, RPC operation, and notification definitions within the input module(s).

The following information is reported for each identifier:

object type (e.g., leaf, container, rpc)
local name for the object (indented for each descendant node)

Example report for module 'yuma-mysession':

identifiers:
  rpc get-my-session
    container output
      leaf indent
      leaf linesize
      leaf with-defaults
    container input
  rpc set-my-session
    container input
      leaf indent
      leaf linesize
      leaf with-defaults
    container output

leaf tree-identifiers {
  type empty;
}

Syntax	empty
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --tree-identifiers --module=yuma-mysession

--unified

The --unified parameter indicates if submodules should be combined into the main module for yangdump-pro translation output. Any include statements will be replaced by the module definitions contained within the submodule.

If set to 'true', then submodules will be processed within the main module, in a unified report, instead of separately, one report for each file.

For translation purposes, this parameter will cause any sub-modules to be treated as if they were defined in the main module. Actual definitions will be generated instead of an 'include' statement, for each submodule.

If this mode is selected, then submodules will be ignored:

If entered with the --module parameter explicitly.
If found when searching for main YANG files to process in a directory, e.g., for the --subtree parameter.

If set to 'false', then a separate output file is generated for each input file, so that XSD output and other reports for a main module will not include information for submodules.

Note

This parameter must be set to 'true' for SIL and SIL-SA code generation.

leaf unified {
  type boolean;
  default false;
}

Syntax	boolean
Default:	false
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --unified=true --format=html --subtree=$PROJECT_X/modules --defnames=true --output=$PROJECT_X/html

--urlstart

The --urlstart parameter specifies the string to start all URLs during yangdump-pro HTML translation.

If present, then this string will be used to start all HREF links and URLs generated for SQL and HTML translation. It is expected to be a URL ending with a directory path. The trailing separator '/' will be added if it is missing.

If not present (the default), then relative URLs, starting with the file name will be generated instead.

For example, if this parameter is set to the following string:

http://acme.com/public

The URL generated for the 'bar' type on line 53, in the module FOO (version 2008-01-01) would be:

if --versionnames=false:
```
http://acme.com/public/FOO.html#bar.53
```

if --versionnames=true (default):

http://acme.com/public/FOO_2008-01-01.html#bar.53

leaf urlstart {
  type string;
}

Syntax	string (URL format)
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --urlstart="/example.com/public/" --unified=true --format=html --subtree=$PROJECT_X/modules --defnames=true --output=$PROJECT_X/html

--versionnames

The --versionnames parameter indicates that revision dates should not be used when constructing any output YANG module file names.

If present, the default filenames will not contain the module version string. Normally, the [sub]module name and version string are both used to generate a default file name, when the --defnames output parameter is set to 'true'. This parameter will cause filenames to be generated which do not contain the revision date string.

leaf versionnames {
  type boolean;
  default true;
}

Syntax	boolean
Default:	true
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --versionnames=false --subtree=/testpath --defnames=true --output=~/work3 --format=html

--xsd-schemaloc

The --xsd-schemaloc parameter specifies that yangdump-pro XSD translations should include the 'schemaLocation' attribute.

If present, then the 'schemaLocation' attribute will be generated during XSD translation. This will be done for the module being processed, and any modules that are imported into that module.

If not present (the default), then the 'schemaLocation' attribute is not generated during XSD translation.

Relative URLs for include and import directives will be generated, starting with the file name.

For example, if this parameter is set to the following string:

http://example.com/public

The 'schemaLocation' XSD for the module test3 (version 10-19-2008) would be:

If --versionnames=false:

xsi:schemaLocation='http://netconfcentral.org/ns/test3
http://example.com/public/test3.xsd'

if --versionnames=true (default):

xsi:schemaLocation='http://netconfcentral.org/ns/test3
http://example.com/public/test3_2008-10-19.xsd'

Note

This parameter is no longer supported because XSD translation is no longer supported.

leaf xsd-schemaloc {
  type string;
}

Syntax	string (URL formal)
Default:	none
Min Allowed:	0
Max Allowed:	1
Supported by:	yangdump-pro
Example:	yangdump-pro --xsd-schemaloc="http://example.com" --format=xsd --module=test3 --defnames=true