Common options

The following are common options of the register_ae utility.

--sig <function(<arg>)>
Specifies the SQL function name and input argument signature. The signature must be double quoted to prevent the shell from interpreting the parentheses literally. For example:
--sig "applyResult(varchar(16), double)"
It is possible to define a function that takes a variable number of arguments by using the "varargs" keyword. For example:
--sig "applyOperation(varargs)"

For a complete list of supported data types, see the Netezza Database User's Guide. For more information about signatures, see the Netezza User-Defined Functions Developer's Guide.

--return <value_type>
Sets the return value or return table of the function. For example, for a scalar function or aggregate:
--return double
For a table function:
--return "table(total double, label varchar(128))"
For a table function, the return type must be double quoted to prevent the shell from interpreting the parentheses literally. It is possible to define a function that returns a table that is defined at runtime with the shaper API by using the "any" keyword. For example:
--return "table(any)"
--language {system | cpp | java | fortran | perl | python64 | python3x| r}
Sets the programming language that is used to write the AE. Accepted options are system (for the base C API), cpp (for C++), java, fortran, perl, python64, python3x (for Python version 3.x) and “r”. For example:
--language java
Note: For information about how to install R, see the IBM developerWorks Netezza Developer Network (NDN) community. You need to register first at developerWorks https://www.ibm.com/developerWorks. Search for “NDN” to locate the Netezza Developer Network community. Follow the instructions in the overview page to get access to the private part of the community.
--template <registration_type>
Defines the registration type. Look at the language's template directory for a complete list. Common option values include:
  • udtf that is a table function
  • udf that is a scalar function
  • uda that is an aggregate function
  • udtf64 that is 64-bit version of udtf
  • udf64 that is a 64-bit version of udf
  • uda64 that is a 64-bit version of uda
    Note: Not all languages support 64-bit operation.
For example:
--template udtf
--version <version>
Sets the AE version in use. This value is tied to the current IBM Netezza analytics version, and is used to track incompatibility. You can display the contents of /nz/export/ae/adapters/system_ae/ to list versions. For example:
--version 3
--db <system_db>
Selects the target Netezza system database (the database where the registration occurs) and the default location of output files. By default (if –db is not specified), the target database is the database set in the Linux environment variable NZ_DATABASE. For example:
--db dev
--user <db_user>
Sets the database user name. This option also helps determine the default location of registration input files. By default (if --user is not specified) register_ae uses the Linux environment variable NZ_USER. For more information, see User definition. For example:
--user Joe_User
--pw <password>
Sets the database password. By default (if --pw is not specified) register_ae uses the Linux environment variable NZ_PASSWORD. For example:
--pw MyPassword

The register_ae utility also supports nzpassword caching. nzpassword is a NPS system command-line utility.

--level {0 | 1 | 2 | 3}
Controls the log file output. Following are descriptions of the log levels. Each level includes output of the lower levels. Higher numbers provide more information that might be useful for technical support.
Table 1. Log levels
Level Description
Level 0 No information and disables logging.
Level 1 Basic, user-level information about the execution run. The amount of data output is fixed.
Level 2 The child (AE) side of the inter-process communication. The amount of data output is variable and can be large.
Level 3 The parent (NPS) side of the inter-process communication. The amount of data output is variable and can be large.
For example:
--level 1
--exe <filename>
Specifies the name of an executable object, a Python script file name, or a Java JAR file. With Java, because exe is only needed when using JAR files, and Java can use class files directly, the use of --exe to specify a JAR file is optional. For example:
--exe <executable>
--exe apply.jar
--exe applyop.py
--define
An optional switch that can be used to set specific template variables, controlling the output mode. For example:
--define templatevar=value
--define java_class=<class_name>
Specifies the Java class to execute. The --exe option is used to specify a JAR file. You must specify at least one of thee options, and both can be specified. For example:
--define java_class=org.netezza.sample.ApplyDriver
Note: This is a specific example of a more general option that is used within the Template Toolkit used to implement compile_ae and register_ae. The general form is --define <template_variable>=<value>.
--path <pathname>
Sets the directory path to the location of the input files. For example:
--path /nz/export/ae/applications/special
Note: The output location for compile_ae files and the input location for register_ae files for a specific application must match. The register_ae utility searches for files in the location where compile_ae deploys files. This can be configured by using the default database settings, by specifying the same database options for compile_ae and register_ae, or by using the --path option.
--warn
Provides a warning instead of an error, allowing processing to continue, if the output location does not start with <ae_export_dir>/ae/applications/<ae_db>. Warning applies only if you are using a non-standard output location with the --path option. For example:
--warn