1 of 9

Utilities

User information update (hwm_update_accounts)

This utility allows inserting of new user accounts and/or updating the user information stored in accounts with additional information which could not be imported for what reason ever from LDAP (e.g. company, e-mail, phone numbers, etc.). It is stored in the bin subdirectory of the ProcMan installation. For to start it, change in the directory where ProcMan is installed (with cd command in the command window or by setting the work directory in a scheduler) and execute the command:

Windows:

bin\hwm_update_accounts.cmd -f <input_file> -c <configuration_id>

Unix:

bin/hwm_update_accounts.sh -f <input_file> -c <configuration_id>

In the execution command replace the <input_file> with the file name (including an absolute or relative path) of the input file containing the user information and the <configuration_id> with a valid configuration id of the required configuration from the configuration file etc/hwm_update_accounts_config.php. Take care that the configuration id is case sensitive so it has to be tipped exactly like it is specified in the configuration file.

The input file has to be a plain text file containing the additional information for users for which the account information shall be updated. Each line of the file has to represent the information about one user and has to contain the user id. A good example for an acceptable input file is a file in a comma separated file format.

Before the utility can be started the structure of the input file has to be described in the configuration file etc/hwm_update_accounts_config.php of the ProcMan installation. Let us explain the content of the configuration file on an example:

<?php
$hwm_update_accounts_config = array(
    'ignore' => array(
        array(
            'pattern' => '/^Surname;Title;Forename;Phone;Company;UserID;Email$/i',
        ),
    ),
    'user_info' => array(
        array(
            'pattern' => '/^([^;]*);([^;]*);([^;]*);([^;]*);([^;]*);([^;]*);([^;]*)$/',
            'user' => array(6),
            'description' => array(2, ' ', 3, ' ', 1),
            'company' => array(5),
            // 'department' => array(),
            'telephone' => array(4),
            // 'mobile' => array(),
            'email' => array(7),
        ),
    ),
    'config' => array(
        'UPDATE_ONLY' => array(
            'update' => true,
            'insert' => false,
            // 'ignore' => array(...),
            // 'user_info' => array(...),
        ),
        'UPDATE_INSERT' => array(
            'update' => true,
            'insert' => true,
            'client' => 'GLOBAL',
            'case_sensitive' => false,
            // 'db_authentication' => true,
            'ldap_host' => 'ldaps://localhost:636',
            'ldap_port' => 0,
            'ldap_chng_password' => true,
            'ldap_server_type' => 'RACF',
            'ldap_password_id' => 'userpassword', 
            'ldap_dn' => 'racfid=<USER>,profiletype=user,cn=racfa,o=horizont,c=de',
            'ldap_test_user' => '',
            'ldap_test_password' => '',
            // 'zos_name' => 'EXAMPLE',
            // 'zos_host' => '192.168.1.1',
            // 'zos_port' => 20000,
            // 'zos_member' => 'ROTJSRVD',
            // 'ignore' => array(...),
            // 'user_info' => array(...),
        ),
    ),
);
?>

In the mandatory section config the configurations for which the utility can be started has to be specified. There must be at least one configuration described in this section. Each configuration must have a unique configuration id specified. In the example above there are two configurations having configuration ids UPDATE_ONLY and UPDATE_INSERT. When starting the utility, the required configuration has to be selected by tipping its configuration id in the -c parameter.

In each configuration ignore and user_info sections like described above can be defined as well. The difference is that the definitions done outside of configurations take effect for all configurations, while the definitions done in a configuration take effect only for this configuration. When starting the utility, the definitions done outside of configurations (if any) and in the selected configuration (if any) are merged. Beware that there must be at least one valid user_info specification either outside of configurations or inside of the selected configuration, otherwise the utility ends with an error.

If the value of the configuration parameter update is true, for all users read from the input file already having an account in ProcMan, the accounts will be updated using the information read from the input file. If update is false, all users read from the input file already having an account in ProcMan are ignored and no update takes place.

If the value of the configuration parameter insert is true, for all users read from the input file not having an account in ProcMan yet, new accounts are being created. If insert is false, all users read from the input file not having an account in ProcMan yet are ignored and no accounts creation takes place.

At least one of the configuration parameters update and insert must be true, otherwise the utility ends with an error.

The configuration parameter client is required only if insert is true. In this parameter a name of an existing ProcMan client has to be specified. This informs the utility in which client the new accounts shall be created.

The configuration parameter case_sensitive has effect only if insert is true. If the parameter is set true, the user names tipped at the ProcMan login will be handled by the newly created accounts as case sensitive (abc ≠ ABC). If the parameter is set false, they are handled as case insensitive (abc = ABC).

The configuration parameter db_authentication has effect only if insert is true and if ldap_host is not specified. If the parameter is set true, the users of the newly created accounts will be authenticated by the database at the ProcMan login. If the parameter is set false, the passwords in all new accounts will be initialized with the user name in lowercase and users will be authenticated by ProcMan itself at the ProcMan login.

The configuration parameter ldap_host has effect only if insert is true. In this parameter the host of the LDAP system which shall authenticate the users for which new accounts are created by the utility. The value can be specified as an IP address, a DNS name or a URL (ldap://<host>:<port>, ldaps://<host>:<port>).

The configuration parameter ldap_port has effect only if insert is true and ldap_host is set and not specified as a URL. In this parameter the port number on the LDAP host defined in ldap_host has to be specified.

The configuration parameter ldap_chng_password has effect only if insert is true and ldap_host is set. It specifies whether the inserted users will be allowed to change their LDAP password from ProcMan.

The configuration parameter ldap_server_type has effect only if insert is true and ldap_host is set. It specifies the LDAP system/backend type. The value RACF (case insensitive) specifies that the inserted users will be authorized by a RACF backend via LDAP. For other LDAP servers/backends the value must be different from RACF. To specify a proper type here is important because changing of a password via LDAP works different for RACF and for other LDAP servers/backends.

The configuration parameter ldap_password_id has effect only if insert is true and ldap_host is set. If ldap_server_type is different than RACF it must be specified and not empty. Otherwise ldap_chng_password is automatically set to false. It specifies the name of the password attribute in the LDAP structure of the user data. For RACF this parameter is ignored.

The configuration parameter ldap_dn has effect only if insert is true and ldap_host is set. In this parameter the DN pattern for the new accounts created by the utility has to be specified. It must contain the place holder <USER> which is replaced with the user name for each newly created account by the utility.

The configuration parameter ldap_test_user has effect only if insert is true and ldap_host is set. This parameter is optional and can contain a user name which (if specified) is used by the utility to verify the connection to the LDAP system specified in the previous LDAP parameters.

The configuration parameter ldap_test_password has effect only if insert is true, ldap_host is set and ldap_test_user is set. In this parameter the encrypted password (generated by the encryption tool in the ProcMan’s administration dialog) for the user defined in ldap_test_user can be specified.

The configuration parameter zos_name has effect only if insert is true. In this parameter the name of the z/OS authentication system configuration which shall be used for the user authentication can be specified. If a configuration with this name is not defined yet, the utility creates the definition.

The configuration parameter zos_host has effect only if insert is true and zos_name is set. In this parameter the host of the z/OS system which shall authenticate the users for which new accounts are created by the utility. The value can be specified as an IP address or a DNS name.

The configuration parameter zos_port has effect only if insert is true and zos_name is set. In this parameter the port number of the HORIZONT z/OS utilities service (also known as HORILST) on the authentication z/OS system has to be specified.

The configuration parameter zos_member has effect only if insert is true and zos_name is set. In this parameter the member name of the HORIZONT z/OS utilities handler (also known as HORJSRV) on the authentication z/OS system has to be specified.

Role assignment (hwm_update_user_roles)

This utility allows assigning of roles to users in specified clients. It is stored in the bin subdirectory of the ProcMan installation. For to start it, change in the directory where ProcMan is installed (with cd command in the command window or by setting the work directory in a scheduler) and execute the command:

Windows:

bin\hwm_update_user_roles.cmd -f <input_file> -c <configuration_id>

Unix:

bin/hwm_update_user_roles.sh -f <input_file> -c <configuration_id>

In the execution command replace the <input_file> with the file name (including an absolute or relative path) of the input file containing the user information and the <configuration_id> with a valid configuration id of the required configuration from the configuration file etc/hwm_update_user_roles_config.php. Take care that the configuration id is case sensitive so it has to be tipped exactly like it is specified in the configuration file.

The input file has to be a plain text file in comma separated format containing the role assignment information. Each line of the file has to represent the information about one assignment of a role to a user in a client. Thus each line has to contain a user id, a role id and a client id.

Before the utility can be started the structure of the input file has to be described in the configuration file etc/hwm_update_user_roles_config.php of the ProcMan installation. Let us explain the content of the configuration file on an example:

<?php
$hwm_update_user_roles_config = array(
    'csv_delimiter' => ';',
    'csv_columns' => 'user;client;role',
    'csv_ignore_first_line' => false,
    'config' => array(
        'DEFAULT' => array(
            // Using above defaults
        ),
        'EXAMPLE_CONFIG' => array(
            'csv_delimiter' => ',',
            'csv_columns' => 'role,user,client',
            'csv_ignore_first_line' => true,
        ),
    ),
);
?>

The configuration parameter csv_delimiter specifies the delimiter of ids in the input file. In a comma separated file format it is normally either semicolon (;) or comma (,).

The configuration parameter csv_columns specifies the order of the three ids (user, client and role) in a line in the input file. It must contain the three key words user, client and role in the string value. Actually the value string can contain any other text in the beginning, at the end and in between of the key words and the key words need not to be even separated. But for better readability we recommend to specify it as a string containing the key words separated by the delimiter specified in the configuration parameter csv_delimiter.

The configuration parameter csv_ignore_first_line specifies whether the very first line of the input file is handled as a header and thus ignored. Possible values are true or false.

In the mandatory section config the configurations for which the utility can be started has to be specified. There must be at least one configuration described in this section. Each configuration must have a unique configuration id specified. In the example above there are two configurations having configuration ids DEFAULT and EXAMPLE_CONFIG. When starting the utility, the required configuration has to be selected by tipping its configuration id in the -c parameter.

In each configuration each (none, one, several or all) of the above configuration parameters can be overridden, which has effect only for the configuration itself. If not overridden the configuration parameter values specified outside of the config section are used for the configuration.

Certificate request generation (hwm_cert_request)

This utility generates a certificate request (for an X.509 certificate) and a key files. The certificate request can then be sent (without the key file) to the certification authority (CA) which has to sign it and send back the final certificate. Such a certificate and the key file can then be used to configure the Web-Server for an encrypted https communication. For to start it, change in the directory where ProcMan is installed (with cd command in the command window) and execute the command:

Windows:

bin\hwm_cert_request.cmd

Unix:

bin/hwm_cert_request.sh

Follow the dialog and answer the questions about the information needed to generate the certificate request and key files. The output of the utility looks like this:

Export of libraries from archive (hwm_export_zos_library)

This utility allows exporting of z/OS libraries from ProcMan’s archive into a file. This file can be for example transferred to the z/OS system, a temporary library containing members in the archive can be created from the file and the temporary library can be compared with the ProcMan’s target library to find out, whether there are changes in the target library done outside of ProcMan. The utility is stored in the bin subdirectory of the ProcMan installation. For to start it, change in the directory where ProcMan is installed (with cd command in the command window or by setting the work directory in a scheduler) and execute the command:

Windows:

bin\hwm_export_zos_library.cmd -f <output_file> -c <configuration_id>

Unix:

bin/hwm_export_zos_library.sh -f <output_file> -c <configuration_id>

In the execution command replace the <output_file> with the file name (including an absolute or relative path) of the output file in which the library in the archive shall be exported and the <configuration_id> with a valid configuration id of the required configuration from the configuration file etc/hwm_export_zos_library_config.php. Take care that the configuration id is case sensitive so it has to be tipped exactly like it is specified in the configuration file.

Before the utility can be started the library which shall be exported from the archive has to be described in the configuration file etc/hwm_export_zos_library_config.php of the ProcMan installation. Let us explain the content of the configuration file on an example:

<?php
$hwm_export_zos_library_config = array(
    'library' => 'P390A.PM30.JOBLIB',
    'archive' => 'JCL',
    'system' => 'PMPROD',

    'config' => array(
        'JOBLIB' => array(
        ),
        'SYSIN1' => array(
            'archive' => 'SYSIN',
            'library' => 'P390A.PM30.SYSLIB',
        ),
        'SYSIN2' => array(
            'archive' => 'SYSIN',
            'library' => 'P390A.PM30.SYSLIB2',
        ),
    ),
);
?>

In the parameter library the ProcMan’s target library which shall be exported has to be specified.

In the parameter archive the archive type of the library has to be specified. Currently only one of the values 'JCL', 'SYSIN', or 'PROC' is meaningful for this parameter.

In the parameter system the system id of the exported target library has to be specified. The proper value for this parameter can be found in the 'system_mapping' section of the etc/hos_config2.php file in the value of the 'id' parameter.

In the config section configurations has to be defined. Meaningful is to define at least one configuration. The global parameters defined outside of the config section are used for all configurations unless they are overridden in single configurations. Each configuration has to have an id and a subsection in which the global parameters can be overridden. The id of the configuration is being used in the –c parameter in the execution command of the utility to specify the configuration using which the utility shall be executed.

If the utility finds some members in the archive it writes an entry for each member to the output file. Each member entry starts with a line like this:

./ ADD NAME=<member_name>

This line is followed by the content of the member. The output file can be transferred to the z/OS system in text mode (with code page conversion) for example using ftp. On the z/OS system a JCL for extracting the members from the transferred file in a temporary library and for comparing the temporary library with the reference library looks like this:

//PMJCLCMP JOB  (DEFAULT),
//        'PROCMAN     ',NOTIFY=&SYSUID,REGION=0M
//**********************************************************************
//* CREATE JOBLIB, BASED ON ARCHIVE UNLOAD AND COMPARE WITH TARGET LIB
//**********************************************************************
//IDCAMS   EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
 DEL P390A.PM30.DATA.OUT.J001
 SET MAXCC = 0
//************************************************************
//* LOAD MEMBERS INTO JCL-PDS
//************************************************************
//LOADMEM  EXEC PGM=IEBUPDTE,PARM='NEW',COND=(4,LT)
//SYSPRINT DD SYSOUT=*
//SYSIN    DD DSN=P390A.PM30.DATA.OUT,
//            DISP=SHR
//SYSUT2   DD DSN=P390A.PM30.DATA.OUT.J001,
//            DISP=(,CATLG),
//            SPACE=(TRK,(500,500,50)),
//            DCB=(DSORG=PO,RECFM=FB,LRECL=80)
//************************************************************
//* COMPARE ARCHIVE-LIB WITH ZOS TARGET-LIB
//************************************************************
//SUPERC  EXEC PGM=ISRSUPC,
//            PARM=(DELTAL,LINECMP,
//            ' SEQ',
//            '')
//NEWDD  DD DSN=P390A.PM30.JOBLIB,
//          DISP=SHR
//OLDDD  DD DSN=P390A.PM30.DATA.OUT.J001,
//          DISP=SHR
//OUTDD  DD SYSOUT=*

In the example above: P390A.PM30.DATA.OUT contains the transferred file generated by the utility, P390A.PM30.DATA.OUT.J001 is the temporary library and P390A.PM30.JOBLIB is the reference library.

Report generation (hwm_process_report)

This utility allows generation of process reports from filters specified in ProcMan or plugins implemented for this purpose in ProcMan. It can generate one or several reports. Reports generated from filters have a similar structure to the ProcMan’s work list. Reports generated from plugins contain one or several tables the content of which is dependent on the plugin implementation. Finally it sends a statistics file and files containing the generated reports in either CSV or HTML format as attachments in an E-mail. The reports can optionally be copied into a specified target directory on the server. For to start it, change in the directory where ProcMan is installed (with cd command in the command window or by setting the work directory in a scheduler) and execute the command:

Windows:

Unix:

In the execution command replace the <configuration_id> with valid configuration ids of the required configurations from the configuration file etc/hwm_process_report_config.php. Take care that the configuration ids are case sensitive so they have to be tipped exactly like they are specified in the configuration file. There can be specified as many configuration ids as many reports the generated E-mail shall contain.

Before the utility can be started the structure of the input file has to be described in the configuration file etc/hwm_process_report_config.php of the ProcMan installation. Let us explain the content of the configuration file on an example:

In the parameter description the description of the report has to be specified. It is used as a header for the report statistic in the statistics file in the mail attachment.

In the parameter mail_subject the subject of the text which appears in the subject of the sent mail has to be specified.

In the parameter mail_text the text of the mail has to be specified.

In the parameter mail_recipients a list of e-mail addresses to which the mails shall be sent has to be specified.

In the parameter mail_attachment_stats_prefix the prefix of the file name of the statistics file sent in the mail attachment has to be specified.

In the parameter mail_attachment_stats_suffix the suffix of the file name of the statistics file sent in the mail attachment has to be specified.

In the parameter mail_attachment_prefix the prefix of the file name of the report file sent in the mail attachment has to be specified.

In the parameter mail_attachment_suffix the suffix of the file name of the report file sent in the mail attachment has to be specified.

In the parameter stats_output_format the format of the statistics file in the mail attachment has to be specified. Possible values are 'CSV' or 'HTML'.

In the parameter output_format the format of the report file in the mail attachment has to be specified. Possible values are 'CSV' or 'HTML'.

In the parameter csv_delimiter the delimiter character for the CSV format has to be specified.

In the parameter csv_enclosure the enclosure character for the CSV format has to be specified. It specifies which character is used to enclose the values which contain special characters.

In the parameter report_dir a directory can be specified where the generated reports shall be copied.

In the parameter report_from the type of the report generator has to be specified. Possible values are 'filter' or 'plugin'.

In the parameter language the language for translation has to be specified. Possible values are 'en' for English or 'de' for German language.

In the parameter time_zone the time zone in which the time values shall be converted has to be specified.

In the parameter date_format the format of the date values displayed in the report has to be specified.

The parameter generate_index specifies whether to write the report entry index in the first column of the report tables (value true) or not (value false).

In the parameter client the client for which the report shall be generated has to be specified.

In the parameter user the user which shall be used for the report generation has to be specified.

In the parameter filter the private filter of the user has to be specified.

The parameter report_activities specifies whether there shell be generated only process entries (value false), or also activity entries (value true) in the reports.

In the parameter plugin the plugin class used for the report generation has to be specified. Currently following plugin classes are implemented:

hwm_report_example – just an example (report containing two constant tables)

hwm_report_db_query – report containing result of a specified SQL query

In the parameter plugin_report_name a speaking description of the plugin has to be specified.

In the parameter plugin_params the plugin specific parameters has to be specified.

In the config section configurations has to be defined. Meaningful is to define at least one configuration. The global parameters defined outside of the config section are used for all configurations unless they are overridden in partial configurations. Each configuration has to have an id and a subsection in which the global parameters can be overridden. The ids of the configurations are being used in the –c parameter in the execution command of the utility to specify the configurations using which the utility shall be executed.

For inline documented examples of the configurations please see etc/hwm_process_report_config.php.sample in the ProcMan installation.

Triggering autoexecution of activities (hwm_autoexec)

Alternatively to the triggering of autoexec activities by the Automaton service (see chapter Automaton), the triggering can be done by this utility. For to start it, change in the directory where ProcMan is installed (with cd command in the command window or by setting the work directory in a scheduler) and execute the command:

Windows:

bin\hwm_autoexec.cmd <parameters>

Unix:

bin/hwm_autoexec.sh <parameters>

Following parameter combinations are possible:

hwm_autoexec -s [-pe process_id [...]] [-ae activity_id [...]] [-f] [-ip] [-i pattern [...]] [-e pattern [...]]
hwm_autoexec -p process_id [...] [-ae activity_id [...]] [-f] [-ip] [-i pattern [...]] [-e pattern [...]]
hwm_autoexec -a activity_id [...] [-f] [-ip] [-i pattern [...]] [-e pattern [...]]

The parameter -s, with the meaning Search for activities with fulfilled autoexec condition in all processes and execute them, has to be specified when the started command shall trigger all autoexecuted activities in the work list which have fulfilled preconditions (proper status and fulfilled autoexecution condition) for an execution.

After the parameter -i, with the meaning Execute only activities with action name matching one of the specified patterns, one or several action name patterns can be specified, to limit the started command only to trigger autoexecuted activities with fulfilled preconditions to those, for which the action name is matching at least one of the specified patterns. The pattern strings can contain wildcards: asterisk (*) and question mark (?). Asterisk means any string even an empty. Question mark means any character.

After the parameter -e, with the meaning Execute only activities with action name not matching one of the specified patterns, one or several action name patterns can be specified, to limit the scheduled command only to trigger autoexecuted activities with fulfilled preconditions to those, for which the action name is not matching any of the specified patterns. The pattern strings can contain wildcards: asterisk (*) and question mark (?). Asterisk means any string even an empty. Question mark means any character.

If the parameter -f, with the meaning Execute activities regardless if their autoexec condition is fulfilled or not, is specified, the check of the fulfilled precondition for triggering of the autoexecuted activities considers only the proper status of the activity and not whether the in the process definition specified autoexecution condition is fulfilled or not.

If the parameter -ip, with the meaning Execute final activities regardless if the predecessor process is completed or not, is checked, also autoexecuted activities which are final activities of processes are triggered even when the pre-processes of the processes are not complete yet.

After the parameter -p, with the meaning Search for activities with fulfilled autoexec condition in specified processes and execute them, one or several process ids (numbers) can be specified to limit the triggering only to autoexecuted activities of the specified processes.

After the parameter -pe, with the meaning Exclude activities of the specifed processes from execution, one or several process ids (numbers) can be specified to avoid the triggering of autoexecuted activities of the specified processes.

After the parameter -a, with the meaning Execute the specified activities if their autoexec condition is fulfilled, one or several activity ids (numbers) can be specified to limit the triggering only to the specified autoexecuted activities.

After the parameter -ae, with the meaning Exclude the specified activities from execution, one or several activity ids (numbers) can be specified to avoid the triggering of the specified autoexecuted activities.

Before the utility can be started the settings required by the autoexecution has to be set in the configuration file etc/hwm_autoexec_config.php of the ProcMan installation. For the description of the configuration settings please see the inline documentation in etc/hwm_autoexec_config.php.sample.

Maintenance of the custom_data table (hwm_custom_data)

The maintenance utility for the data stored in the custom_data table allows importing of data from a comma separated data file (CSV) into the table, deleting data from the table and displaying the content of the table. Each of these functions can be applied in a separate call only for one kind of data specified by the data type identifier.

For to start the utility, change in the directory where ProcMan is installed (with cd command in the command window or by setting the work directory in a scheduler) and execute the command:

Windows:

bin\hwm_custom_data.cmd -i <instruction> -t <data_type> [-c <configuration_id>] [-f <file>]

bin\hwm_custom_data.cmd -c <configuration_id> [-i <instruction>] [-t <data_type>] [-f <file>]

Unix:

bin/hwm_custom_data.sh -i <instruction> -t <data_type> [-c <configuration_id>] [-f <file>]

bin/hwm_custom_data.sh -c <configuration_id> [-i <instruction>] [-t <data_type>] [-f <file>]

<instruction> is the instruction which shall be executed and it can be either import, or delete, or show.

<data_type> is the data type identifier of the data kind for which the instruction has to be applied.

<configuration_id> is a valid configuration identifier of the required configuration section from the configuration file etc/hwm_custom_data_config.php.

<file> is the file path to the CSV file containing the data to be imported.

For the instructions delete and show the -f parameter is not required and not used. In this case the utility can be called simply with the -i and -t parameters. The -c parameter is not required in this case as well. It makes only sense to use it, if one or both of the parameters -i and -t are omitted in the call and the instruction and/or the data type identifier are specified in a configuration section (specified in the -c call parameter) of the configuration file.

For the instruction import the -c parameter is mandatory, as the import requires parameters, which can only be specified in the configuration file. The parameters instruction, data type identifier and file can be specified either in the call parameters (-i, -t, -f) or in the configuration section (specified in the -c call parameter) of the configuration file.

Parameters specified in the call have a higher priority than those specified in the configuration file.

Let us explain the content of the configuration file etc/hwm_custom_data_config.php on an example:

<?php
$hwm_custom_data_config = array(
    'instruction' => 'import',
    'type' => '',
    'csv_file' => '',
    'csv_delimiter' => ';',
    'csv_enclosure' => '"',
    'csv_escape' => '\\',
    'csv_columns' => 'data_str_1,data_str_2,data_str_6',
    'csv_key' => 'data_str_1,data_str_2',
    'csv_ignore_first_line' => false,

    'config' => array(
        'DEFAULT' => array(
            // Using above defaults
        ),
        'SUBJECT_IMPORT' => array(
            'instruction' => 'import',
            'type' => 'SUBJECT',
            'csv_columns' => 'data_str_1,data_str_3',
            'csv_key' => 'data_str_1',
            'csv_ignore_first_line' => true,
        ),
    ),
);
?>

The parameter instruction is the instruction which shall be executed and it can be either import, or delete, or show. It corresponds to the call parameter -i.

The parameter type is the data type identifier of the data kind for which the instruction has to be applied. It corresponds to the call parameter -t.

The parameter csv_file is the file path to the CSV file containing the data to be imported. It corresponds to the call parameter -f.

The parameter csv_delimiter specifies the character used to separate partial values in the CSV file. Usually it is either the comma (,) or the semicolon (;).

The parameter csv_encolsure specifies the character used to enclose values containing special characters (e.g. new lines) in the CSV file. Usually it is the double quotation mark (").

The parameter csv_escape specifies the character used for escaping special characters in the values in the CSV file. Usually it is the backslash ().

The parameter csv_columns specifies which columns in the CSV file correspond to which columns in the custom data table. The value is a list of column descriptors separated by either the comma (,) or the semicolon (;). Only columns of the CSV file, where the column descriptor is matching a column name of the custom_data ProcMan table, are considered for the import. The following column names of the custom_data table can be used in the list of column descriptors: data_int_1, data_int_2, data_str_1, data_str_2, data_str_3, data_str_4, data_str_5 and data_str_6.

The parameter csv_key specifies which custom_table columns build the key in the rows imported from the CSV file. Imported rows overwrite records in the custom_data table having the same key like the imported row. The value of the parameter is a list of custom_data column names separated by either the comma (,) or the semicolon (;). Only table column names specified also in csv_columns are considered to be a part of the key. If this parameter is not specified or empty, all valid table column names from csv_columns are part of the key of the imported rows.

The parameter csv_ignore_first_line specifies whether the first line in the CSV file is a header line, which shall be ignored on the import (value true), or the first line is already a data line, which shall be imported (value false).

In the config section configurations has to be defined. Meaningful is to define at least one configuration. The global parameters defined outside of the config section are used for all configurations unless they are overridden in partial configurations. Each configuration has to have an id and a subsection in which the global parameters can be overridden. The ids of the configurations are being used in the –c parameter in the execution command of the utility to specify the configurations using which the utility shall be executed.

Benchmark (hwm_benchmark)

The benchmark utility can be used for checking network accessibility and performance of communications used by ProcMan and its modules. Currently implemented benchmark tests allow to check for example the database access, LDAP and z/OS (using the horcclnt utility) authentications, Control-M access, etc.

The configuration for the tool itself and for the benchmark tests is stored in the file etc/hwm_benchmark_config.php and in the files for module specific benchmark tests, e.g. etc/hos_ctm_benchmark_config.php for the Control-M module. The partial options are described in the etc/*.sample versions of these files (e.g. etc/hwm_benchmark_config.php.sample), in in-line comments.

For to start the utility, change in the directory where ProcMan is installed (with cd command in the command window or by setting the work directory in a scheduler) and execute the command:

Windows:

bin\hwm_benchmark.cmd -f <file> [-i <iterations>]

Unix:

bin/hwm_benchmark.sh -f <file> [-i <iterations>]

In the execution command replace the parameter <file> with the file path/name of the file, in which the result of the benchmark, in CSV format, has to be stored. If the .csv extension is missing at the end of the specified file name, the utility adds it automatically.

In the optional parameter -i, the number of iterations (how many times each benchmark test has to be done) can be specified instead of <iterations>. If the number of iterations is missing in the call, a value specified for it in the configuration is being used for it.

The table exported in CSV format contains for all test types the time of the fastest and the slowest test run, the mean test run time evaluated for all iterations, the maximal expected time of each test run, the result of the benchmark and the time information about the start/end of the whole benchmark. The result for each test type is evaluated from the mean time and the expected time. It is declared as fast, if the mean time is lower than the expected time, as slow, if the mean time is greater than the expected time, or as very slow, if the mean time is more than twice as great, as the expected time. If an error occurred during some test run of some test type, the result of the test type is set to error. Error messages are displayed at the end of the output of the utility in such a case.

User information update (hwm_update_accounts)

Windows:

bin\hwm_update_accounts.cmd -f <input_file> -c <configuration_id>

Unix:

bin/hwm_update_accounts.sh -f <input_file> -c <configuration_id>

<?php
$hwm_update_accounts_config = array(
    'ignore' => array(
        array(
            'pattern' => '/^Surname;Title;Forename;Phone;Company;UserID;Email$/i',
        ),
    ),
    'user_info' => array(
        array(
            'pattern' => '/^([^;]*);([^;]*);([^;]*);([^;]*);([^;]*);([^;]*);([^;]*)$/',
            'user' => array(6),
            'description' => array(2, ' ', 3, ' ', 1),
            'company' => array(5),
            // 'department' => array(),
            'telephone' => array(4),
            // 'mobile' => array(),
            'email' => array(7),
        ),
    ),
    'config' => array(
        'UPDATE_ONLY' => array(
            'update' => true,
            'insert' => false,
            // 'ignore' => array(...),
            // 'user_info' => array(...),
        ),
        'UPDATE_INSERT' => array(
            'update' => true,
            'insert' => true,
            'client' => 'GLOBAL',
            'case_sensitive' => false,
            // 'db_authentication' => true,
            'ldap_host' => 'ldaps://localhost:636',
            'ldap_port' => 0,
            'ldap_chng_password' => true,
            'ldap_server_type' => 'RACF',
            'ldap_password_id' => 'userpassword', 
            'ldap_dn' => 'racfid=<USER>,profiletype=user,cn=racfa,o=horizont,c=de',
            'ldap_test_user' => '',
            'ldap_test_password' => '',
            // 'zos_name' => 'EXAMPLE',
            // 'zos_host' => '192.168.1.1',
            // 'zos_port' => 20000,
            // 'zos_member' => 'ROTJSRVD',
            // 'ignore' => array(...),
            // 'user_info' => array(...),
        ),
    ),
);
?>

In the optional section ignore patterns of lines which shall be ignored form the update can be specified. Such lines are typically headers which do not represent any real user. The patterns have to be specified in a form of a regular expression (for detailed information about the syntax of the regular expressions see ). There can be specified more than one pattern in the ignore section by adding further array('pattern' => '…'), statements.

In the optional section user_info patterns of lines which contain the user information can be specified. The patterns have to be specified in a form of a regular expression (for detailed information about the syntax of the regular expressions see ). There can be specified more than one pattern in the user_info section by adding further array('pattern' => '…', 'user' => '…', …), statements. Further for each pattern an assignment of parts of a user line read from the input file to the account data items user (user id), description, company, department, telephone, mobile and email has to be specified in the user_info section. Not all account data items must be filled (except the item user which is mandatory). In the case that the user lines in the input file does not contain some information the assignment to the corresponding account data items can be omitted or commented out like in the case of the item mobile in the example above. The assignment of a part of a read user line to an account data item is done by specifying an integer index of the sub-pattern representing the account data item in the input user line. Sub-patterns are specified by parentheses in the input user line pattern. First sub-pattern has the index 1, the second one the index 2, etc. In the example above the user id is in the matching user line represented by the 6th sub-pattern so in the configuration file it is specified as ‘user’ => array(6). Moreover the assignment can be specified as a concatenation of parts of the user line represented by more than one sub-pattern and string literals. In the example above the item description is made of the title (sub-pattern 2), forename (sub-pattern 3) and surname (sub-pattern 1) delimited by a space (' ') which is specified as 'description' => array(2, ' ', 3, ' ', 1).

At least one of the configuration parameters update and insert must be true, otherwise the utility ends with an error.

Report generation (hwm_process_report)

Windows:

bin\hwm_process_report.cmd -c <configuration_id> [<configuration_id> [...]]

Unix:

bin/hwm_process_report.sh -c <configuration_id> [<configuration_id> [...]]

<?php
$hwm_process_report_config = array(
    'description' => 'Example report',

    'mail_subject' => 'ProcMan: Process Report',
    'mail_text' => 'Process Report generated by the reporting tool.'."\n\n".
                   'See attachment for the report files.',
    'mail_recipients' => array('user1@my_company.com', 'user2@my_company.com'),
    'mail_attachment_stats_prefix' => 'statistics-',
    'mail_attachment_stats_suffix' => '.txt',
    'mail_attachment_prefix' => 'process-report-',
    'mail_attachment_suffix' => '.txt',

    'stats_output_format' => 'CSV',
    'output_format' => 'CSV',

    'csv_delimiter' => ';',
    'csv_enclosure' => '"',

    'report_dir' => '',
    'report_from' => 'filter',
    'language' => 'en',
    'time_zone' => 'Europe/Berlin',
    'date_format' => 'DD.MM.YYYY',
    'generate_index' => true,

    // Filter options:
    'client' => 'HORIZONT',
    'user' => 'user1',
    'filter' => '1WEEK_HISTORY',
    'report_activities' => false,

    // Plugin options:
    'plugin' => 'hwm_report_example',
    'plugin_report_name' => 'Plugin Example',
    'plugin_params' => array(),

    'config' => array(
        'DEFAULT' => array(
        ),
        'TODO_TOMORROW' => array(
            'description' => 'To do list for tomorrow',
            'user' => 'user2',
            'filter' => 'TODO_TOMORROW',
            'output_format' => 'HTML',
        ),
        'HISTORY_LAST_MONTH' => array(
            'description' => 'List of processes completed last month',
            'filter' => 'LAST_MONTH_HISTORY',
        ),
        'PLUGIN_EXAMPLE' => array(
            'report_from' => 'plugin',
        ),
    ),
);
?>