ProcMan 5.0.12 (2025-03-28)

Component: ProcMan Workflow Manager

Component: ProcMan JCL

Component: ProcMan JCL z/OS Part

Component: ProcMan Universal module

Component: ProcMan IWS z/OS

The following table shows the requirements for a ProcMan installation.

*HWF (HORIZONT Web Framework) is an extra product package basic for all our Web Products.

**depends on the number of handover processes.

Please check if connections from the web client (user) to the ProcMan server and from the ProcMan server to the z/OS, to DB2 database and LDAP are open and working.

Also verify if the LDAP server at z/OS is started (standard STC name is GLDRV) and configured for RACF. ProcMan makes the RACF authentication via LDAP.

Please note and maybe report to HORIZONT consultant:

• The alias name of the DB2connect connection (DNS/IP, port, database name)

• The technical user id for the database access

• The qualifier of the table names

• The technical user id for the HORIZONT TCPIP communication task HORISRV

• The technical user id for the IWSz access (AD und CP)

• The technical user id for the Control-M access

• Control-M handover: Some extra reports must be defined.

• IP addresses und ports of: ProcMan Server, z/OS systems including HORILST, database and LDAP server.

• IP address (or DNS name) and port of the SMTP server and a valid user for the SMTP authentication.

Following persons will be needed to do the installation:

• Windows administrator

• DB2 administrator

• z/OS system programmer

• RACF administrator

• LAN- / WAN- / Firewall-Administrator

• IWS or Control-M administrator

• HORIZONT consultant

Basic components

• HWF (HORIZONT Web Frame) Basics for all HORIZONT browser applications, it contains Apache, PHP and optional PostgreSQL

• HWM (HORIZONT Workflow Manager) ProcMan basic part allows you to select, execute and control the defined handover processes.

• Processes used to execute tasks, e. g. JCL validation, generation and copy to the target libraries.

• Databasestores all ProcMan data.

Basic components in detail

ProcMan is a PHP application and runs on a Windows-Server. The data is stored in a database, currently DB2 z/OS or PostgreSQL.

To connect to the DB2 z/OS database, ProcMan is using the IBM Data Server Client (authentication via a specific technical user id).

The user interfaces are web dialogs, running on any browser. In addition, graphic flowcharts can be used to display IWS z/OS flowcharts.

Authentication will be done via LDAP (Active Directory or RACF etc.), or via HORIZONT Listener and RACF, or ProcMan’s own authentication system. Some single sign-on methods are supported, too.

JCL-Checks will be done by HORIZONT product SmartJCL and JCL-Modifications by its ProcMan enhancement, the JCL Generator Language (Rules).

The JCL rules are stored in z/OS PDS-Member, additional parts in the ProcMan database, configuration files (PHP) and in XML files on the Windows Server.

HORIZONT server task HORISRV on z/OS is used to transfer JCL between z/OS and the ProcMan server and to run SmartJCL Analyse/Generator Jobs on z/OS.

To work with IWSz, ProcMan keeps all IWS AD (application description) in the ProcMan database, which is automatically synchronized.

To (optionally) check dependencies between jobs, files and IWSz operations, ProcMan uses the HORIZONT product XINFO JCL scanner and the IWSz scanner.

Email messaging can be done via SMTP server.

ProcMan architecture, if only module “Universal-Object” is used

ProcMan architecture, if modules “JCL” and “IWS z/OS” are used

ProcMan architecture, if module “Control-M” is used

Local Windows administrator user to install the ProcMan programs on the Server.

DBADMIN to create ProcMan’s database.

To install additional HORIZONT products like SmartJCL: “z/OS system programmer rights” (to update proclibs, assign APF rights etc.) ProcMan requires a technical RACF user id to execute programs on z/OS. That user must have following rights:

• Select/Insert/Update/Delete on ProcMan’s DB2 tables.

• Run SmartJCL Jobs

• Read and write to ProcMan’s JCL libraries.

• Read XINFO DB2 tables (optional)

If IWSz handover are used

• Read IWSz VSAM Files AD, WS, LT

• Update IWSz AD/CP by PIF

If Control-M handover are used, the technical user needs:

• full access to read/update Folders in the Control-M Enterprise Manager

• permission to use the Automation API and Control-M Reports

ProcMan JCL Module creates job logs and needs to read these logs from spool on z/OS. Therefor a JES Hold Class must be provided with following parameters:

// OUTCLASS(T) BLNKTRNC=YES,        /* TRUNCATE TRAILING BLANKS          wnc*/
// OUTDISP=(HOLD,HOLD),             /* OUT disp                PRINT    ownc*/         
// OUTPUT=PRINT,                    /* Print Class             PRINT     wnc*/         
// TRKCELL=YES                      /* Track-Cell this Class   NOTRKCEL  wnc*/    

Required firewall authorizations

• Open port ProcMan Server database server (port 446)

• Open port ProcMan Server PC-Clients via https (port 443) or http (port 80)

• Open port ProcMan Server LDAP server (port 389) or Open port ProcMan Server LDAPS (SSL encrypted) server (port 636)

• Open port ProcMan Server and z/OS System(s) / HORILST (port 20000)

• Open port ProcMan Server and Control-M automation API

• Open port ProcMan Server SMTP server (port 25) orOpen port ProcMan Server SMTPS (SSL encrypted) server (port 465)

The ports mentioned above are the defaults. The ports can be changed to your needs.

The customer has to prepare/generate an X.509v3 certificate (and the key file) to setup https communication between the client PC and the ProcMan Server. In addition, the issuer's certificate (so-called CA certificate) must be installed on the client PCs.

Host-Mapping for the Windows Server (DNS names for the host IP Addresses).

If you have a problem that requires technical support, please open a service ticket in our service desk:

HORIZONT Software GmbH Schäufeleinstr. 7, D-80687 München Tel. Germany / (0)89 / 540 162 0 Fax. Germany / (0)89 / 540 162 62

Database client

Before the installation of ProcMan can be started the DB2 Client (the official name of the product is IBM Data Server Client) must be installed on the server where ProcMan shall run. The database client must be installed and configured in a way that client applications can access the database server and the ProcMan database on it from the ProcMan server.

HWF (HORIZONT Web Framework)

HTTPS

If the communication between the user PCs and the ProcMan server shall run via HTTPS protocol (encrypted communication), the certification authority (CA) of the customer has to provide a X.509 certificate and a key file for the ProcMan server.

For the generation of the certificate the CA will need the DNS (domain name system) name or the IP address of the ProcMan server which will be used in the URL (uniform system locator) requests in the browsers on the user PCs to access the ProcMan server (e.g. for URL=https://procman.my_company.com:11443/index.php, DNS=procman.my_company.com).

Authentication

ProcMan allows user authentication against one or several LDAP capable systems (RACF, Active Directory, OpenLDAP, etc.). Such users can be imported into ProcMan either directly from the LDAP systems, or from CSV files.

In the case, that the users shall be imported directly from some LDAP systems, a user which is authorized to read the users list via LDAP is required for each such a LDAP system.

Such a user and he’s authorization has to be provided by the administrators of the LDAP system. For example in RACF, the user used for the LDAP user import needs the ROAUDIT (read-only auditor) attribute, to be able to read the users list via LDAP. It allows to read (but not change) all RACF profiles, and can be set either in ISPF RACF dialog or by the command:

ALU userid ROAUDIT

General Information

This guide describes the installation of ProcMan on a Windows Server or normal Windows PC.

Important

The following guide will describe how to install ProcMan in the directory c:/

After ProcMan has been installed, you can continue setting up processes in ProcMan.

At first, the windows code page should be changed on the target system in order to make sure that the communication with a DB2 database works without problems.

The environment variable DB2CODEPAGE=1208 has to be set on the ProcMan server before the installation of ProcMan can be started. This informs DB2 Client that all strings passed to the database are already UTF-8 encoded and there is no need to encode it again, to store them into tables using UTF-8 encoding. Otherwise the strings inserted into the database tables become longer than expected and eventually cause errors because they exceed the maximal length of database table columns.

There are possible 2 options to do that:

Option A

Use the windows search bar and search for "environment". Open the "Edit environment variables" app. Now click on "environment variables", a new window should appear. In the lower window ("system variables") change the value of the variable "DB2CODEPAGE" to 1208. If the variable doesn't exist, you have to create a new one.

Option B

Open the CLI, and use the commaned set. All defined environment variables should be shown now. In order to change the value of the variable "DB2CODEPAGE" to 1208, execute

set DB2CODEPAGE=1208

To check if the variable was successfully set, type in the command

set DB2CODEPAGE

Overview

This document provides guidance on configuring the IBM DB2 Command Line Interface (CLI) for optimal performance and compatibility with ProcMan. The settings ensure efficient transaction handling and improved performance by adjusting the default behavior of the DB2 client.

DB2 Client Installation

1. Download the latest DB2 Client for Windows (For HORIZONT installations see v:/download/DB2_DSClient_11-1_Win_x86-64).

2. Run the setup.exe, select new installation, and accept the licence agreement. Start the installation.

3. Navigate to the installation directory (e.g. c:/program files/IBM/SQLLIB/BIN/db2cmdadmin.exe) and execute the db2cmdadmin.exe, the Command Line interface (CLI) should open now.

4. Execute the command db2 in the CLI, the DB2-Client CLI should start now.

Connect the client to the database

Now you need to connect to the DB2 Database.

In the ProcMan Installation package, you should see a file called add_connection_example.db2 in the directory /DB2. Open that file in your preferred editor (e.g. notepad++). Copy the last 6 rows (see code below) one after another and execute them in the CLI.

Important: Do not copy the semicolons. You should get positive feedback for each command in the CLI.

Testing the DB2 connection

To test the connection to the HORIZONT DB2 Database, execute the following two commands in the CLI.

You should get a positive response in the CLI, like in the picture below.

Recommended configuration options

The following addtional configurations are recommended.

TXNIsolation

• Setting: TXNIsolation=1

• Meaning: Sets the transaction isolation level to Read Uncommitted

• Effect: Allows dirty reads, enabling higher performance with minimal locking

DB2Optimization

• Setting: DB2Optimization=5

• Meaning: Enables a higher level of CLI optimization

• Effect: Improves execution speed and efficiency by pre-packaging SQL statements more aggressively

Option A: Edit db2cli.ini

This option is recommended if file access is available.

Open the following file: c:\Users\All Users\IBM\DB2\DB2COPY1\cfg\db2cli.ini (beware that this default path of the file can be overwritten in the system variable DB2CLIINIPATH

For older DB2 Client versions the default path is: c:\Program Files\IBM\DB2\DB2COPY1\cfg\db2cli.ini

Add the following lines under the section for your database alias:

Option B: Use DB2 CLI Commands

This option is recommended if no file access is available and if your user is part of the DB2ADMIN group on the ProcMan server.

1. Open the DB2 Command Line Processor (db2cmd) on the ProcMan server

2. Run the following commands:

Replace <DBALIAS> with your configured database alias.

For to check if the options have been set correctly execute the following command:

Catalogue database

The database, which shall be used by ProcMan, has to be cataloged in the DB2 Client in a way that the user authentication is done by the DB2 Server:

This ensures that DB2 Client does not try to authenticate the user used for establishing a database connection on the client system (where DB2 Client is installed), but sends the user information for authentication immediately to the DB2 Server, which leads to a better performance.

Troubleshooting

Licence error

If you get an licence error while executing the command

you need to install a licence. Ask some one like Jörg/Rado for the licence file db2consv_zs.lic, place it on your PC, open the CLI, navigate to the directory where the licence file is stored and execute the command

to install the licence. To check if the licence was installled correctly, execute the command

db2cmdadmin window opens and immediately closes

Connect with the server with remote desktop. Go to computer management and two groups. First, create local DB2ADMNS and DB2USERS groups and add your user to that group. Then, add the Domain Account to one or both of these groups. These groups are the default groups recognized by DB2. Members of the DB2ADMNS group have SYSADMIN Authority. Members of the DB2USERS group do not have SYSADMIN Authority but are able to execute DB2 commands. Also use the CLI (as admin) and execute the command 'db2extsec'.

Next, from a Windows Command Prompt execute:

Now the db2cmdadmin CLI should open and not immediately close.

1. Download installation package

First, the latest procman-X.X.XX.zip (e.g. procman-5.0.12.zip) must be downloaded from the customer portal and then it must be unzipped.

This installation package contains the components HWI (HORIZONT Web-application Interface), HWM (HORIZONT Workflow Manager), and HOS (HORIZONT Hand-Over System).

Login as an administrator on the Windows server where ProcMan shall be installed. Extract the ProcMan setup files from the package procman-5.0.X.zip in a setup directory on the server. Now open the setup directory.

2. Setup setup.rsp file

To install ProcMan, it is recommended to use the setup.rsp file. This is located in the extracted directory and can be edited with any editor. Open the file and adjust the installation opens.

To install ProcMan e.g. with the JCL module (but without IWS), the following parameters should be set in setup.rsp file. Parameters, which are not listed below, must not be adjusted.

Important information

If ProcMan is installed several times on one PC/Server, the APP_URL, APP_INSTALL_NAME, SESSION_NAME etc. must be unique.

HORIZONT_ROOT=C:\Horizont
…
APP_INSTALL_NAME=procman
...
APP_DOCU=Y
…
APP_TWS=N
…
APP_IWD=N

HDB (PostgreSQL)

If the HDB (HORIZONT Database / PostgreSQL) should be used, the parameters for APP_DB_HOST, etc. have to be set.

3. Run the installation

To start the installation, simply run the setup.cmd as administrator. Check all settings again in the CLI. After the installation, the HORIZONT Apache Webserver service needs to be restarted.

ProcMan requires PHP and a Webserver, which we deliver in the so-called HORIZONT Web Framework (HWF). This document only describes how to install HWF for ProcMan.

1. Download HWF

Download the latest HWF installation package from the HORIZONT customer portal (e.g. HWF V6.0.6) and extract it somewhere on the target system.

2. Optional: Install/update the Microsoft Visual Studio C++ runtime

Install/update the Microsoft Visual Studio C++ runtime (MSVC) manually. Navigate to ../hwf/contrib/ and search for all the vcredist_x64-YYYY.exe files. Run them all as administrator.

3. Run the setup.cmd

Now run the setup.cmd in the downloaded HWF package as administrator and follow the installation steps.

Important things to consider:

• In step 1 set the correct installation directory of the existing HWF installation.

• In step 4 choose "no" if you decided to install/update the MSVC manually.

• There is no need to set the TNS_ADMIN and DB2INSTANCE options in the HWF installation dialog for ProcMan, as they are ignored. They can be left empty (which is the default).

• Do not install HDB (HORIZONT Database Module) after the HWF installation, which is asked in the HWF installation dialog after HWF installation finished.

4. Enable full version of DB2 client

There is a light version of the DB2 Client installed with HWF. After the installation of HWF the PATH system variable contains the path to this light version of the DB2 client in the beginning, which disables the full version of the DB2 client required by ProcMan.

To correct this, after HWF installation, remove from the content of the PATH variable the following part:

%HWF_ROOT%\LIB\DB2\BIN;

After changing the content of the PATH variable you have to restart the Web Server (e.g. in Windows’s Services dialog restart the HORIZONT HTTP Server service) before the change takes effect.

5. Verify HWF installation

6. Recommended: Configuring the HWF service to run with a special user

Windows

By default, the HORIZONT HTTP Server service runs under the Local System account, which is highly privileged—more so than a standard administrator account in certain areas. For better security and manageability, it is strongly recommended to run the service under a dedicated local or domain user account with limited privileges.

This guide walks you through:

• Creating or assigning a restricted user

• Granting required filesystem and DB2 access

• Running the service under the new user

• Configuring permissions to allow restarting the service from ProcMan

Step 1: Create or Select a Service User

1. Create a local user in Windows or use an existing local/domain user.

2. Ensure the user has a non-expiring password.

3. Grant this user modify permissions on the HORIZONT installation directory (by default C:\HORIZONT) and all its subdirectories.

Step 2: Assign DB2 Access (if applicable)

If the DB2 Client was installed with Windows Authentication, it creates two local user groups:

• DB2ADMNS

• DB2USERS

Add the service user to the DB2USERS group to allow DB2 access while maintaining minimal privilege.

Step 3: Configure the Service to Run Under the User

1. Open the Services management console:

   Control Panel → System and Security → Administrative Tools → Services

2. Locate the HORIZONT HTTP Server service.

3. Double-click to open its properties and go to the Log On tab.

4. Select "This account", enter the user credentials created/selected in Step 1, and confirm.

5. Click OK and restart the service.

Step 4: Allow the User to Restart the Service via ProcMan

By default, only administrators and system accounts can start/stop services. To allow the non-admin service user to restart the web server (e.g. via ProcMan), follow these steps using the Microsoft Management Console (MMC):

A. Prepare a Custom Security Template

1. Open MMC as administrator:

   • Press Win + R, type mmc, and press Enter.

2. From the menu: File → Add/Remove Snap-in…

3. Add the following snap-ins:

   • Security Templates

   • Click OK

4. In the Security Templates tree, select a directory (e.g., C:\Windows\Security\Templates) and then:

   • Action → New Template

5. Enter a name and (optional) description for the template and click OK.

B. Define Service Permissions in the Template

1. Under your new template, go to: System Services → HORIZONT HTTP Server

2. Right-click and select: Action → Properties

3. In the dialog:

   • Check: "Define this policy setting in the template"

   • Set Startup mode to Automatic

   • Click Edit Security

4. In the security dialog:

   • Add the dedicated service user

   • Grant the permission: Start, stop, and pause

5. Click OK to close all dialogs and save the template.

C. Apply the Security Template

1. Again, open: File → Add/Remove Snap-in…

2. Add: Security Configuration and Analysis Click OK

3. In the snap-in:

   • Action → Open Database

   • Choose a name for the database file (e.g. horizont_service_config)

4. When prompted, select the template you created earlier.

5. Then run: Action → Configure Computer Now

6. After applying, restart the HORIZONT HTTP Server service once manually as an administrator to ensure new permissions take effect.

Important Notes

• These permission changes are persistent and survive system restarts.

• The MMC interface may vary slightly between Windows versions.

• Always verify service functionality after changing its user context or security settings.

Linux

The web server switches automatically after it is started to run under a lower privileged user. So there is nothing to be done explicitly.

If it should be later possible to restart the web server by an administrator from the ProcMan dialog, the user under which the web server is running, has to be authorized to restart the web server. For this the user has to be authorized to start the httpd program as a super user using the sudo command without a tty session and without entering a password. To allow this open the file /etc/sudoers for editing. If there is a line like this

Defaults requiretty

comment it out with a hash (#) in the beginning of the line. Further add a line like this

<httpd_user>     ALL=    NOPASSWD: <http_path>/httpd

in the file /etc/sudoers. Replace <httpd_user> by the proper user name. Replace <httpd_path> by the proper path to the httpd program. For example:

procman     ALL=     NOPASSWD: /usr/sbin/httpd

If a DB2 database is used, ProcMan needs to be able to communicate with the DB2 database. Therefore the DB2 PHP Extension needs to be activated.

To activate the extension, open the installation directory of HWF (c:/HORIZONT/hwf/php/php.d/). Open the file ibm_db2.ini with an editor. To activate the extension, row 6 must not be commented out. If you make changes to the file, the HORIZONT Apache Service needs to be restarted. See the picture below.

How to check if the extension is active:

hos_db_config.php

Important note: During the installation of ProcMan or HWM only the file hwm_db_config.php is created automatically and correctly filled. In all other configuration files, where the database connection, alias, DB user, password etc. appear, the values must be set manually.

So the next thing to do is to adjust the hos_db_config.php file e.g. located in c:/horizont/procman/etc/hos_db_config.php.

This configuration file is used to define the database connection from ProcMan to e.g. the DB2 database (in addition to hwm_db_config.php).

In the 'db' section at the very bottom, the correct "prefix", "alias" and "pwd" (see in the hwm_db_config.php) must be set.

The configuration dialog has the following two parts: Basic configuration, Database configuration. Go through the dialog screens, fill the requested data and continue to the next screen by clicking the Continue button.

First page

Single Sign-on

In this section the Single Sign-on authentication may be selected. Select ‘-‘, if there is none in use. Currently only the IBM Tivoli Access Manager WebSEAL is supported here.

Log file

This section of the dialog allows specifying where to write the log files and what message level shall be logged. If the dialog is started for the first time, the path of the log file is preset depending on the settings in the etc/hwi_config.php file. The file name may contain the sequence $D$, which means that every day will be opened a new log file and the sequence is replaced in the real file name by the current date, e.g.

D:/log/ProcMan/hwm-$D$.log

Following Message levels are accepted:

Intervals for user and activity status update

This section allows configuring the feature that for long time active activities automatically change their status to pending.

The user login status interval specifies how often the information that a user is logged-in is actualized in ProcMan. The value means count of minutes. The value must be an integer greater or equal 0 (zero). If set to 0 (zero) the updating of the user login-in status as well as the automatic change of activity status from active to pending is switched off.

The activity status interval specifies that after the last update user of an active activity is not logged-in for this time, the status of the activity shall be automatically set to pending.

The value means count of minutes. The value must be an integer greater or equal 0 (zero). If set to 0 (zero) the automatic change of activity status from active to pending is switched off.

SMTP

Here the SMTP server for sending alarm e-mails can be configured. If the SMTP server supports SSL encryption it can be used by specifying the SMTP server IP/DNS prefixed by ‘ssl://’ (e.g. ssl://smtp.my_company.com) and the port on which the SMTP server accepts the SSL encrypted communication (default is 465).

Put the IP address or DNS of the ProcMan Server in the Client computer for identification at the server field.

Second page - Database configuration

On the second page, the DB2 parameters must be set so that ProcMan/HWM can communicate with the DB2 database. The customer normally provides the DB2 database information.

The checkboxes for "Create Database", "Initialize Database", and "Only generate Scripts..." should be set.

Detailed description of page 2 - Database configuration

Basically HWF supports following Database system types: DB2 (z/OS), Oracle, PostgreSQL. The dialog differs slightly depending on the Database system type selected.

• The current ProcMan version and HOS (JCL) supports only DB2 on z/OS,

• Special parameters for DB2 are the Alias and the Table Qualifier.

• Special parameters for Oracle are Host (IP address or DNS name), Port and Database Name.

Special parameters for PostgreSQL are Host (IP address or DNS name), Port, Database Name and Schema. Other parameters are the same.

Table name and Index name templates are optional and are dedicated for cases, when the Customer has special conventions for table/index names.

For example if the tables shall be named in the range ABCDT00 – ABCDT99 and indexes in the range ABCDI00 – ABCDI99, put in as the Table name template ABCDT__ and as the Index name template ABCDI__. The __ (two underscores) is then replaced by a running number in the generated SQL statements.

In User, Password and Repeat Password put in the information about the technical user which will be used by HWM for the Database access. The information about the technical user will be stored in a configuration file, the password will be encrypted.

Check the Drop database checkbox if you want to replace already existing Database.

Check the Create Database checkbox if:

• you want that a new Database (schemas, tables, indexes, etc.) shall be created by the dialog

• the Database already exists and you want to drop it and create newly,

• you want only to generate the Database definitions in a file. The file can be reviewed and maybe send to z/OS and executed there by e.g. SPUFI or a batch job.

Check the Initialize Database checkbox if:

• you want to fill a newly created Database with initial data,

• you want to delete all data in the Database and initialize it newly.

Check the Migrate data checkbox if:

• you want to migrate data in a newly created migration database,

• you want to reinitialize the data in the current database with the data from an existing migration database.

If at least one of the Create Database and Initialize Database checkboxes is checked and the dialog is submitted, the configuration procedure generates a file DBDefinition.sql in the database subdirectory of the ProcMan installation. It contains all SQL statements needed for creation and/or initialization of the database. This file has no influence on the run of HWM.

It may be useful if you do not have database administration rights at the time of HWM configuration. In this case you can send this file to your database administrator to check, adjust and execute the SQL statements in this file.

If none of the Create Database and Initialize Database checkboxes is checked and the dialog is submitted, only the Database access settings are saved.

Check the ‘Only generate scripts checkbox’ if you only want to generate the SQL statements into the file database/DBDefinition.sql described above without creating and/or initializing the database.

If the Drop/Create Database checkbox has been checked a further dialog is being shown after submitting.

The user specified in admin user and password is being used only for the Database creation. The information about the admin user will not be stored anywhere (in opposite to the technical user on the previous screen).

The Database Name, Table Space, Database creation parameters, Tablespace creation parameters, Table creation parameters and Index creation parameters fields are shown only in the DB2 variant of the dialog. Put in meaningful parameters as they will be used for the Database creation. The Table Space name may contain a sequence of two or more underscores to specify that for every table a new table space shall be created. The sequence of underscores is in the generated SQL statements replaced by a running number like in the Table name and Index name templates in the previous dialog screen.

The Database/Tablespace/Table/Index creation parameters may contain any parameters accepted by DB2 for the respective database object type. When the dialog is running for the first time they are initialized by default values.

In the Users to be admin granted parameter database users which shall be granted to be admins of the database can be specified as a list (one user name in each line).

The Only generate scripts checkbox is the same like on the previous screen.

Protection of the Configuration dialog

Because the Configuration dialog is being started via an Internet Browser it could be started later by any user of HWM from any client computer. To allow this could have fatal follow-ups because everyone could change the HWM configuration. Therefore the Configuration dialog has a built in protection. At the end of the first successful run of the dialog, it generates a file hwm_install_blocker.php in the etc subdirectory of the ProcMan installation. This file contains only one option:

$hwm_install_blocker = true;

If the file exists and the value of the option $hwm_install_blocker in the file is true, every try to start hwm_install.php by any user ends with an error message. If you need to start the Configuration dialog later, you have two possibilities:

• delete the etc/hwm_install_blocker.php file

• set the value of the option $hwm_install_blocker in the etc/hwm_install_blocker.php file to false

If you delete the etc/hwm_install_blocker.php, you will be allowed to start the Configuration dialog only once. At the end it generates the etc/hwm_install_blocker.php again and disables repeated starts.

If you change the value of the option $hwm_install_blocker in the etc/hwm_install_blocker.php file to false, you will be able to start the Configuration dialog arbitrary times. Do not forget to change the value of the $hwm_install_blocker option back to true at the end of your configuration work. Otherwise the protection is switched off and any user may start the Configuration dialog from any client computer.

Finishing the setup

With a click on "Continue" the HWM setup is completed.

In case of a re-setup of HWM

The file hwm_db_config.php is overwritten after finishing the setup. All other files in case of an existing ProcMan installation are not changed.

Now there should be a DBDefinition.sql file in the installation directory, e.g. in c:/horizont/procman/database/.

This DBDefinition.sql file contains all queries to created the tables needed for the Procman installation. The file should be forwarded to the responsible DB2 administrator. He needs to execute the SQL queries contained in the file to create the tables needed for the ProcMan installation on the DB2 database.

In case you have administration rights on the DB2 database

Follow the steps below to run and execute the queries in the DBDefinition.sql file.

1. Start the db2cmdadmin.exe as admin. A CLI should open.

2. Type and execute the command db2

3. Connect to the database.

connect to <Database> user <zOSUser>

1. Execute the command "quit"

2. Navigate with the command cd to the directory where the DBDefinition.sql file is located.

3. Execute the file with the following command.

–tvf DBDefinition.sql

You should see a lot of successful responses that the commands have been executed successfully.

Now the HWM setup is complete. Finally, it is recommended to check the parameters contained in the hwm_db_config.php file in the installation directory (e.g. c:/horizont/procman/etc/hwm_db_config.php) to check if everything is correct (e.g. db_alias, db_name).

Additional information

In the next step, the file c:/horizont/procman/etc/hos_config2.php must be adjusted.

This is the most important file to start with, because in this file most of the configurations for a ProcMan installation come together. E.g., in this file it is defined which systems should be connected with ProcMan and also which environment variables should be used for the processes.

Section system_mapping

In the section system_mapping systems are defined in an array that should be connected with the ProcMan installation. In this section it is defined which IP is associated with which ID.

Important: Generally, the IP addresses have to be unique! This can be "bypassed" by assigning IP addresses to names in the c:/Windows/System32/drivers/etc/hosts file on the windows server. See the picture below.

For example, at HORIZONT, the z/OS with the IP 192.168.47.14 has to be defined in the section system_mapping. Therefore, we add a variable in the pm_system_settings.php file e.g. named $TEST_ip and assign the value 'TEST' to that variable. That means that the windows server now resolves 'TEST' to the IP 192.168.47.14 because this was set in the hosts file (as shown in the picture above).

In the following example (see picture below), we defined two systems in the hos_config2.php file. If you check the assigned variables' values in the pm_system_settings.php file, you can see that both systems are identical because they have equal IPs. The IP for the system DEV is directly defined in the hos_config2.php file, for the system DEMO the ip is resolved by windows through the c:/windows/system32/drivers/etc/hosts file.

Section environment

In this section. it is defined which config files for environment definitions should be used. These hos_env_XXX.php files contain environment definitions for processes in ProcMan.

It is recommended to create a seperate hos_env_<module>.php file for every module which is used in an installation, e.g. one for the jcl_proccesses named hos_env_jcl.php, one for IWS/AD processes named hos_env_iws_ad.php, and one for IWS/CP processes named hos_env_iws_cp.php. These files must then be included in the hos_config2.php file.

Important: The definitions in those files need to start at the correct array-layer, make sure not to mess that up, otherwise this can break ProcMan.

The picture below shows an example of three env_config files placed in the directory /etc/env_configs/. One for the JCL module, one for the IWS/AD module and one for the IWS/CP module.

Section zos_tech_user

In this section, it is defined which z/OS user is used for which system with which password. Here it is also highly recommended to use variables defined in the pm_system_settings.php file.

Section rot_ini_file

In the section rot_ini_file it is defined which system (see above section system_mapping) uses which .ini file for the communication to the z/OS systems.

Important: After a new installation most probably no .ini file was created. Therefore a new file with the name e.g. horcclnt.ini has to be created. Use the file /procman/etc/horcclnt.ini-dist to make a new copy for your system. If multiple z/OS systems are connected to ProcMan, create multiple files with different names like horcclnt_test.ini or horcclnt_prod.ini .

The example below illustrates two possible communications to a TEST and a PROD system.

The variables starting with $ are e.g. resolved from the pm_system_settings file as this:

horcclnt.ini files

The following adjustments have to be made in the .ini files. Row 14: Correct path Row 18: Correct path Row 26: Optional: Adjust log path Row 50: Set the correct host port from the installation of ProcMan z/OS part Row 54: Set the correct member from the installation of ProcMan z/OS part

Sections template_dsn_cntl, base_tmp_dsn and temp_dsn_alloc_site

In the section template_dsn_cntl it is defined, which dataset on the z/OS contains the skeletons for the ProcMan JCL Module.

In the section base_tmp_dsn it is defined, which dataset is used when the ProcMan JCL modules creates outputs. Those members are also defined in the installation of the z/OS part of ProcMan.

As described in the article before, in the hos_config2.php files, multiple environment files are included.

These hos_env_<module>.php files contain environment settings that are relevant for the processes in ProcMan.

In most cases, there should also be a hos_env_general.php file. This environment file can be seen as a fallback and contains environment settings that should be used for all clients and processes if no other environment files have been defined.

For a detailed description of all the environment parameters of the hos_config2.php file, please see:

Process specific environment configuration

In most installations, processes require individual environment configurations.

See the code example below which shows an example of a hos_env_jcl.php file.

From line 3 to 51 a general environment config is set.

From line 58 to the end, the environment setting for a specific process with the name JCL_INIT_CO is set. This means that this config will "overwrite" the lines 3 to 51, because it is process specific.

If the client systems (user workstations, proxies, single sign-on systems, etc.) sending client certificates to the web server along with HTTPS requests and a verification of these certificates is required following settings must be done. After this is configured all the requests sent from systems not providing valid client certificates will be rejected.

Copy the certification authority (CA) certificate file of the CA which released the client certificates into the httpd/config.d subdirectory of the HWF installation.

Add the following lines (if they are not already there) in the section of the .conf configuration file of the Web Server of ProcMan:

SSLVerifyClient require
SSLVerifyDepth 10
SSLCACertificateFile conf.d/<ca_certificate_file>
<Location />
 SSLRequire <client_certificate_check>
</Location>

Replace <ca_certificate_file> with the real name of the CA certificate file you previously copied to httpd/config.d.

Replace <client_certificate_check> with an expression for the client certificate validation.

For more information of how these expression looks like, see the Apache documentation (http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslrequire) and the example below.

Example (.conf):

...
<VirtualHost procman.my_company.com:11443>
 ...
 SSLVerifyClient require
 SSLVerifyDepth 10
 SSLCACertificateFile conf.d/company_ca.crt
 <Location />
 SSLRequire %{SSL_CLIENT_S_DN_O} == "My Company Ltd." \
 && %{SSL_CLIENT_S_DN_OU} == "My Company CA" \
 && %{SSL_CLIENT_S_DN_CN} == "procman_client.my_company.com"
 </Location>
 ...
</VirtualHost>
...

The ProcMan server certificate and key file provided by the CA (see prerequisites) has to be copied into the httpd/conf.d subdirectory of the HWF installation. Beware that the certificate file must be in X.509 Base64 encoded PEM format.

You can verify whether this is the case by opening it in a text editor. If it is in the proper format, it must not contain any binary data and it must contain a section like this:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

If the file contains binary data instead, the certificate is probably in the DER format and it has to be converted into the Base64 encoded PEM format. For the conversion you can either use the openssl command:

openssl x509 -inform DER -in <DER encoded file> -out <PEM encoded file>

or (only on Windows) open the certificate file by double click from the Windows Explorer in the Windows Certificate tool and copy it into a Base64 encoded PEM file:

The names of the files set in the Web Server configuration file are by default .crt and .key where is the installation name set in the setup.rsp at the ProcMan installation. If the certificate and key file names differ from these, rename them or open the Web Server configuration file in a text file editor and change the file names in the options SSLCertificateFile and SSLCertificateKeyFile.

...
<VirtualHost procman.my_company.com:11443>
 ...
 SSLCertificateFile "C:/Programs/Horizont/webapps/hwf/conf.d/other_name.crt"
 SSLCertificateKeyFile "C:/Programs/Horizont/webapps/hwf/conf.d/other_name.key"
 ...
</VirtualHost>
...

The default Web Server configuration created at the installation of ProcMan is for an encrypted HTTPS communication between the clients and the ProcMan server. It is strongly recommended not to change this configuration to an unencrypted HTTP communication. However if there is some crucial reason for this it can be done in the Web Server configuration file .conf by changing the port number and commenting out the options starting with SSL by using the '#' at the start of the row.

For example:

It is highly recommended to use HTTPS and a HTTPS certificate for ProcMan.

The default Web Server configuration created at the installation of ProcMan is for an encrypted HTTPS communication between the clients and the ProcMan server.

It is strongly recommended not to change this configuration to an unencrypted HTTP communication. However if there is some crucial reason for this it can be done in the Web Server configuration file <name>.conf by changing the port number and commenting out the options starting with SSL.

You need a .crt and a .key file which you can get from an official licensing site or from your companies certificate department.

1. Place the .crt and .key file in C:\HORIZONT\hwf\httpd\conf.d

2. Open the C:\HORIZONT\hwf\httpd\conf.d\<installationname>.conf file. In there, under the VirtualHost section, change the SSLCertificateFile path and the SSLCertficcateKeyFile path to the files added above.

Optionally ProcMan can be configured for exchanging data with external systems. This feature is typically used to connect an external ticket system, which allows associating ProcMan processes with tickets managed by the ticket systems, filling ProcMan process dialog fields with data from tickets and reporting ProcMan process/activity status changes back to the external system. The communication is managed by a ProcMan module called HWM Universal Interface. An important prerequisite is that the external system provides an HTTP/HTTPS server interface. ProcMan can currently be configured only as a client of the communication and does not provide any server service for handling request from external systems.

As any external system provides its own communication protocol (the form of the requests/responses and security requirements), configuration of the communication in ProcMan means to set special options and implementing some callback functions. Thus the configuration of the communication always requires HORIZONT support. To be able to configure it, a precise specification of the protocol provided by the external system is required.

The specification of the protocol shall provide at least answers to following questions:

Is it an encrypted communication, are CA and/or client certificates required and who provides them? Over what URL is the external system accessible? What method shall the request use: GET or POST? What is the structure of a request, what has to be sent in GET/POST parameters, what in http headers, what in http data? Are there some special data required in the request by the external system (e.g. authentication string, special http headers, etc.)? What format (JSON, XML, etc.) and structure (attribute/tag names, data types, etc.) shall the request data have? What format (JSON, XML, etc.) and structure (attribute/tag names, data types, etc.) have the response data? What data are sent in the http response headers and what in the http response data by the external system? Are there special responses in case of errors sent by the external system and what structure they have? Shall also the activity/process status changes be reported by ProcMan to the external system? If yes, what are the answers to the above questions for this kind of communication? Can all open tickets be requested by one request from the external system or only data for one in the request specified ticket?

If the user login shall work via encrypted secure LDAP communication (LDAPS), there have to be set some system environment variables to configure the LDAPS communication and after that the Web Server has to be restarted (e.g. in Windows’s Services dialog restart the HORIZONT HTTP Server service). On Unix/Linux the setting of the system variables works as well, but the preferred way is to set appropriate options in the ldap.conf file (see the description for this later in this chapter).

No server certificate verification required

If server certificate verification by the client is not required, set the environment variable LDAPTLS_REQCERT=never

Server certificate verification required

If server certificate verification by the client is required, copy the certificate of the server certificate’s authority provided by the customer to a file on the ProcMan server (e.g. C:\Programs\HORIZONT\ldap\server_ca.crt). If the server certificate has been issued using an intermediate authority certificate, which self has been signed by a parent authority certificate, copy all the chain of the intermediate authority certificate and all its ancestor authority certificates in arbitrary order in a single file on the ProcMan server.

Set the environment variables LDAPTLS_REQCERT=try and LDAPTLS_CACERT=<file>, where <file> is the file with its absolute path containing the certificate of the server certificate’s authority (or chain of authority certificates) previously copied to the ProcMan server.

Client certificate verification required

Beside the server certificate verification by the client, also client certificate verification by the server can be required for the secure LDAP communication in some installations. In this case a client certificate file and its private key file provided by the customer and issued by an authority known to the server has to be copied to files on the ProcMan server (e.g. C:\Programs\HORIZONT\ldap\client.crt and C:\Programs\HORIZONT\ldap\client.key). Beware that the key file has to be protected to avoid its misuse.

Set the environment variables LDAPTLS_CERT=<cert_file> and LDAPTLS_KEY=<key_file>, where <cert_file> is the client certificate file and <key_file> is the private key file, with their absolute paths, previously copied to the ProcMan server.

On Unix/Linux the preferred way is to set appropriate options in the ldap.conf file, rather than use the system variables. In a HWF installation the ldap.conf file is placed in /opt/horizont/hwf/etc/ldap.conf. The configuration options corresponding to the system variables described above are TLS_REQCERT, TLS_CACERT, TLS_CERT and TLS_KEY. The required options can be added by editing the ldap.conf file.

Example (ldap.conf):

TLS_REQCERT try
TLS_CACERT /opt/horizont/my_company_ca.crt

Please see Setting up TLS Communication

HWF Update

It is recommended to make a backup of the HWF directory before doing a HWF update.

Optionally you can activate the maintenance mode in /etc/hwi_config.php

1. Download

Download the latest HWF package and place it on the target system. Login to the target system with remote desktop.

2. Stop all HORIZONT Services

Go to the windows search, search for "services", open the services app and search for HORIZONT services.

Alternative: Open task manager and go to the services tab.

Rightclick on all HORIZONT services and stop them.

In case of ProcMan IWS, also stop all IWS Systems synchronisations.

3. Optional: Install/update the Microsoft Visual Studio C++ runtime

Install/update the Microsoft Visual Studio C++ runtime (MSVC) manually. Navigate to .../hwf/contrib/ and search for all the vcredist_x64-YYYY.exe files. Run them all as administrator. Every MSVC package needs to be installed on the system. If the installer asks for "repair", you can cancel the installation because this package is already installed.

4. Run the setup.cmd

Now run the setup.cmd in the downloaded HWF package as administrator and follow the installation steps.

5. Restart Services

Now restart all the services.

ProcMan Update

Important

If you are updating a productive environment of ProcMan, it is recommended to lock the web app by setting hwi_config.php - Maintenance to "true".

It is also recommended to stop all IWS-Synchronisations in ProcMan if the IWS module is used.

It is strongly recommended to make a backup of the .../HORIZONT/procman/ directory before updating the ProcMan installation. Just make a copy of that directory and rename it to something like backupprocmanYYYYMMDD

1. Download

Download the latest ProcMan package and store it on the target system. Log on to the target system with remote desktop.

2. Use the existing setup.rsp file and update it

Recommended: Use (and update) the existing setup.rsp file from a previous installation. This isrecommended because configurations from an earlier installation are reused and not changed. If you choose to use the setup.rsp file from the downloaded package, all parameters have to be set again. Errors might occur easily when doing that.

3. Run the setup.cmd

Now run the setup.cmd file as administrator in the installation directory and make a final check that all parameters (especially the installation directory) are set correctly.

4. Final check

Check if the installation was successful. In case of ProcMan IWS, start the IWS systems synchronisation.

z/OS

• If you are using ProcMan Job-Control module then HORIZONT’s SmartJCL must be installed first.

• If HORILST is used for communication, SmartJCL Remote Check must also be installed.

• Since ProcMan z/OS part version 5.1, TLS is mandatory. Please see Setting up TLS Communication

• Unpack the installation file on Windows and transfer to z/OS

• Adjust template jobs for JCL analysis / generation

• Post installation: define basic JCL Rules

1. Download and extract installation files

Copy PRXINST.ZIP to a temporary Windows directory and unzip it. The following files will be created:

• PRXINST.BIN

2. Transfer files to the HOST

The unzipped file must be transmitted to the HOST by file transfer.

3. Create at HOST the XMIT file

4. Transfer the unzipped file to the created Host-XMIT file

With a file transfer program, you must send the following PC files to the HOST.

Transfer mode must be binary.

The options ASCII and CLRF are not allowed.

5. Generate the program files by the TSO command RECEIVE.

RECEIVE INDSNAME(‘PREFIX.XMITINST’)

6. Delete HOST-XMIT file ‘PREFIX.XMITINST’

7. Adapt the installation job to your environment and submit this job.

HLQ.PROCMAN.VxRxFIX.INSTALL(PMJFXnn).

//OPGJFXnn JOB CLASS=A,MSGCLASS=T,                                    
// NOTIFY=&SYSUID                                                     
//*                                                                   
//* - RECEIVE XMIT FILES FOR A PROCMAN 5.0 FIX                        
//*                                                                   
//* NECESSARY ADAPTIONS:                                              
//* 1) CHANGE THE NAME OF 'USERID.PROCMAN.V5R0FIX.INSTALL' TO YOUR    
//*    NEEDS. IT IS THE OUTPUT DSN OF YOUR PREVIOUS TSO RECEIVE       
//*    COMMAND THAT CONTAINS THIS MEMBER.                             
//* 2) CHANGE 'HLQ.PROCMAN.V5R0' TO YOUR PROCMAN INSTALLATION DSNS.   
//********************************************************************
//*                                                                   
//RECEIVE  EXEC PGM=IKJEFT01,REGION=32M                               
//SYSPRINT DD SYSOUT=*                                                
//SYSTSPRT DD SYSOUT=*                                                
//SYSTSIN  DD *                                                       
 RECEIVE INDSN('USERID.PROCMAN.VxRxFIX.INSTALL(LOAD)')                
 DATASET('HLQ.PROCMAN.VxRx.LOAD') +                                   
 RELEASE                                                              
 RECEIVE INDSN('USERID.PROCMAN.VxRxFIX.INSTALL(REXX)')                
 DATASET('HLQ.PROCMAN.VxRx.REXX') +                                   
 RELEASE                                                              
 RECEIVE INDSN('USERID.PROCMAN.VxRxFIX.INSTALL(PANELS)')              
 DATASET('HLQ.PROCMAN.VxRx.PANELS') +                                 
 RELEASE                                                              
 RECEIVE INDSN('USERID.PROCMAN.VxRxFIX.INSTALL(LREXX)')               
 DATASET('HLQ.PROCMAN.VxRx.REXXLOAD') +                               
 RELEASE                                                             

The following files will be created:

The Job-Control which is used by ProcMan Web-Dialog was stored in library HLQ.PROCMAN.SKELS. After installation, you will find all members for sample client HORIZONT. For a new client all example members must be copied with a new name. These new members must be modified according to your company's requirements.

It has proven itself to use the first two characters in member names as client abbreviation. You will be asked for that during the installation dialog. E.g. HO = HORIZONT

The members are skeleton JCL for the ProcMan programs. The dataset names and member names must also be defined in configuration files on ProcMan windows server.

Below you will see an example skeleton.

//##JOBNAME##   JOB  'DEFAULT','PROCMAN JOB', MSGCLASS=H,CLASS=A          
//* RESOLVED FROM SCELETON HOSJCHKC                    
//JOBLIB   DD  DISP=SHR,DSN=MYDATA.SMARTJCL.V3R0.LOAD        
//         DD  DISP=SHR,DSN=USER.PM.LOAD                      
//DEL      EXEC PGM=IDCAMS                             
//SYSPRINT DD  DUMMY                                   
//SYSIN    DD  *                                       
 DELETE ##HOSXOUT##                                    
 DELETE ##SYSPRINT##                                   
 DELETE ##SYSTSPRT##                                   
 DELETE ##JCKSUMO##                                    
 DELETE ##JCKDTLO##                                    
 IF MAXCC=8 THEN SET MAXCC = 0                         
/*                                                     
//RFMT     EXEC PGM=JCKIRFMT,REGION=0M                          
//SYSIN    DD  DISP=SHR,DSN=SYS1.SMARTJCL.V3R0.PARM(JCKKPARM)  
//         DD  *                                       
    USE-SRI=N                                          
    USE-HOS=N                                          
//##JUPJINAME-R## DD DISP=SHR,DSN=##JUPJIDSN-R##               
………………………………..          

Variables that are replaced by ProcMan are limited with ‘##’ at the beginning and at the end of a variable. Do not modify or delete these variables.

There are example member with Rules and parameter stored in library HLQ.PROCMAN.RULES. These members must be adapted to your Requirements. The importance of the members and the parameters are described in the following chapters.

Various job control examples are also provided with the installation.

• xxSADUMP Process transfer to HORIZONT

• xxSJCUST Create SQL for filling DB2 table CUSTOM_DATA

• xxSJDELD Deleting temporary process files

• xxSJFCNT Create SQL for filling DB2 table FORMCONT

• xxSJVSFL Create VSAM Check file for JCL rules

1. Download and extract installation files

Copy PRXINST.ZIP to a temporary Windows directory and unzip it. The following files will be created:

• PRXINST.BIN

2. Transfer files to the HOST

The unzipped file must be transmitted to the HOST by file transfer.

3. Create at HOST the XMIT file

4. Transfer the unzipped file to the created Host-XMIT file

With a file transfer program, you must send the following PC files to the HOST.

Transfer mode must be binary.

The ASCII and CLRF options must not be used.

5. Generate the program files by the TSO command RECEIVE

RECEIVE INDSNAME(‘PREFIX.XMITINST’)

6. Delete HOST-XMIT file ‘PREFIX.XMITINST’

7. Start the installation

Start the installation by executing the following member with line command=EX HLQ.PROCMAN.VxRx.INSTALL(PMIXINST).

It displays the menu where you select the components you want to install. The following screenshots describe the installation dialogs for all components.

PMIPDI15 ------------- Installation of ProcMan-Host-Files --------------------
Command ===>                                                                   
                                                                               
Before you start the installation, the HORIZONT products "SmartJCL"  
and HORIZONT "Shared Package" must be installed.                     
                                                                     
Note The IWS part must be installed if you want to check Job-Control 
     with IWS variable substitution.                                 
                                                                     
ProcMan zOS installation with IWS variable substitution  ===> _  Y/N 
                                                                     
ENTER continue CAN/END Abend installation.                                     

• ProcMan zOS installation with IWS variable substitution If SmartJCL jobs will be started with IWS variable substitution some IWS parameter must be entered.

PMIPDI20 ------------- Installation of ProcMan-Host-Files --------------------
Command ===>                                                                   
Installation Library                                                           
  Receive Library      ===> HLQ.PROCMAN.V3R3.INSTALL_____________________                         
                                                                               
ISPF Libraries                                                                 
  Tables               ===> ISP.SISPTENU_________________________________                                        
  Message              ===> ISP.SISPMENU_________________________________                                       
  Skeleton             ===> ISP.SISPSENU_________________________________                                       
  Panels               ===> ISP.SISPPENU_________________________________                                       
  Load	   		===> ISP.SISPLOAD_________________________________
If the ISPF libraries cannot be determined automatically, please add the
library names manually.                                                 
                                                                        
Enter SmartJCL-Parameter-Library where member JCKXPARM is stored        
  SmartJcl Parm-Lib.   ===> SYSH.SMARTJCL.PARM___________________________                          
Enter name of Load-Library from HORIZONT "Shared Package"               
  Shared Load library  ===> HORIZONT.SHARED.V1R3.LOAD____________________                      
                                                                         
ENTER continue  CAN/END Abend installation.                              

Enter the dataset name of your transfer dataset. Normally the name is inserted automatically.

The names of the ISPF Libraries are automatically determined. If the fields are empty you have to type the correct dataset names manually. In some system environments is an automatic determination not possible.

SMARTJCL must be installed first. Enter the name of the SMARTJCL parameter library where member JCKXPARM exists. This member is analysed in order to obtain the required parameter.

PMIPDI25 ---------- Installation of ProcMan Product datasets------------------
Command ===>                                                                   
                                                                               
ProcMan Product Datasets. Libraries are for administration dialog.             
  REXX                 ===> SYSH.PROCMAN.VxRx.REXX______________________                             
  REXX Load            ===> SYSH.PROCMAN.VxRx.LOAD.REXX_________________                        
  Load                 ===> SYSH.PROCMAN.VxRx.LOAD______________________                             
  Edit Macro           ===> SYSH.PROCMAN.VxRx.EMAC______________________                             
  Messages             ===> SYSH.PROCMAN.VxRx.MESSAGE___________________                          
  Panels               ===> SYSH.PROCMAN.VxRx.PANELS____________________                           
                                                                               
  Note! Product user needs update rights for following datasets:               
  Parameter            ===> SYSH.PROCMAN.VxRx.PARM______________________                             
  Tables               ===> SYSH.PROCMAN.VxRx.TABLES____________________                      
  Skels                ===> SYSH.PROCMAN.VxRx.SKELS_____________________                       
  Log File             ===> SYSH.PROCMAN.VxRx.LOG_______________________ 
  HOSXIN (Rule macro)  ===> SYSH.PROCMAN.VxRx.MACRO.HOSXIN______________                        
                                                                               
  This file is only temporary and contains all generated skeleton member.      
  Qualifier WorkDSN    ===> SYSH.PROCMAN.VxRx.WRK__________     '.TEMP.CNTL'  
                                                                               
ENTER continue  CAN/END Abend installation.                                    

Enter the dataset names for your installation. HLQ is a placeholder and the dataset names are just a suggestion.

You can customize the names according to your Requirements.

PMIPDI30 ------------ Installation of ProcMan User Dataset -------------------
Command ===>                                                                   
                                                                               
ProcMan User Datasets                                                          
Note! User datasets are usually created with another qualifier.                
      Following datasets are created with an own job.                          
                                                                               
  Rules                ===> SYSH.PROCMAN.VxRx.RULES______________________                            
  Example JCL          ===> SYSH.PROCMAN.VxRx.JCL________________________                              
  SYSIN                ===> SYSH.PROCMAN.VxRx.SYSIN______________________                            
  ProcMan JCL Scels    ===> SYSH.PROCMAN.VxRx.JCL.SKELS__________________                        
  ProcMan JCL Message  ===> SYSH.PROCMAN.VxRx.JCL.MESSAGE________________                      
  Check VSAM dataset   ===> SYSH.PROCMAN.VxRx.CHECK.VSAM_________________                       
  Check ISPF dataset   ===> SYSH.PROCMAN.VxRx.CHECK.ISPF_________________                       
                                                                               
ENTER continue  CAN/END Abend installation.                                    

Enter the dataset names for your installation. HLQ is a placeholder and the dataset names are just a suggestion.

You can customize the names according to your Requirements.

In a typical installation software product libraries and user libraries are separated by dataset qualifier and permission. It is called user datasets because the software user has maintained these datasets and not the person who made the installation.

PMIPDI40 ------------- Installation of ProcMan-Host-Files --------------------
Command ===>                                                                   
                                                                               
TWS Datasets and Parameter                                                     
  TWS Version  ===> J  F V9R1, G V9R2, H V9R3, I V93R3, J V9R5, K V10R1     
  Subsystem    ===> IWJC                                                       
  EQQMLIB      ===> SYSH.IWS950.SEQQMSG0___________________________                                       
  SEQQLMDM     ===> SYSH.IWS950.SEQQLMD0___________________________                                       
  AD File      ===> SYSH.IWJC.AD___________________________________                                               
                                                                               
ENTER continue  CAN/END Abend installation.                                   

If you are using ProcMan with IWS handover you have to type the IWS datasets too. Within IWS processes can also job control actions are invoked. The entered parameter will be used for IWS JCL templates.

PMIPDI50 ------------- Installation of ProcMan-Host-Files --------------------
Command ===>                                                                   
                                                                               
Parameter for Job-Control generator. Program uses entered values to generate   
the Job-Control skeleton for Web-Dialog.                                       
Member name:    ===> HO  enter first two digits of new skeleton member         
Jobcard:       (Set unused parameter to blank)                                 
  Account       ===> (DEFAULT,92) _____________________________________________                                              
                     Enter with ' ' or ( )                                     
  Class         ===> A      Msgclass ===> H      Msglevel ===> 1  1  (e.G. 1 1)
  Prty          ===> 7      Region   ===> 0M     User     ===> _________                
  Schenv        ===> ______________  Enter without ' '                         
  Cond          ===> ______________  Enter without ' ' or ( )                  
Joblib/Steplib: ===> J  N=none J=Joblib S=Steplib                              
                                                                               
DD parameter:                                                                  
  SYSOUT Class  ===> *                                                         
Enter only if required:                                                        
  Step Account  ===> __________________________________________________________                                                          
  UNIT          ===> ________    VOLSER         ===> ________                          
  Storage class ===> ________    Data class     ===> ________                          
  Managem.class ===> ________                                                          
For JES3 installation inserts parameter for //*MAIN                            
Enter parameter only. //*MAIN will be inserted automatically.                  
-//*MAIN ===> _________________________________________________________________                                                                  
ENTER continue CAN/END Abend Installation.                                    

ProcMan JCL Web dialog will submit SmartJCL jobs. These jobs will be stored as templates at zOS. To generate these templates, you need to specify certain parameters.

PMIPDI55 ------------- Installation of ProcMan-Host-Files --------------------
Command ===>                                                                   
                                                                               
Enter DB2 parameter. Entered values are used for DB2 load batch job.           
                                                                               
DB2 Subsystem      ===> DBAX                                                   
Program for Load   ===> DSNTEP2_                                                
Plan name          ===> DSNTEPA1                                               
Load  (*.SDSNLOAD) ===> DSNA10.SDSNLOAD_____________________________                                        
Utility Load       ===> DSNA10.DBAG.RUNLIB.LOAD_____________________                                
Table Owner        ===> PMXX_999                                               
                                                                               
ENTER continue  CAN/END Abend installation.                           
                                                                        

DB2 parameter are used for an administration batch job. This job will fill DB2 table FORMCONT. This table will be used for checks with web dialog.

PMIPDI60 ------------- Installation of ProcMan-Host-Files --------------------
Command ===>                                                                   
                                                                               
Jobcard for Installation Job                                                   
===> //USERX33 JOB  (DEFAULT),________________________________________________                                                
===> //        'PROCMAN HFX',NOTIFY=&SYSUID___________________________________                                    
===> //*______________________________________________________________________                                                                       
===> _________________________________________________________________________                                                                          
                                                                               
For JES3 installation inserts parameter for //*MAIN                            
Enter parameter only //*MAIN will be inserted automatically                    
-//*MAIN ===> ________________________________________________________________                                                                  
                                                                               
Parameter for Installation Job                                                 
- SYSOUT                    ===> *                                             
- Qualifier for workfiles   ===> HLQ.PROCMAN.VxRx.WRK_______________                        
Enter only if required                                                         
- UNIT                      ===> SYSDA__                                         
- VOLSER                    ===> _______                                              
- Storage class             ===> _______                                              
- Data class                ===> _______                                              
- Management class          ===> _______                                              
- Step Account              ===> ________________________________________                                              
                                                                               
ENTER Continue  CAN/END Abend Installation.                                    

Please enter the Job Control parameter for installation job. After job was generate it will be shown with ISPF edit.

+-------------------------------------------------------------+
|  Create Member in temporary Library                         |
|  USER.PROCMAN.TEMP.CNTL                                     |
|                                                             |
|  Member total    : 50         8   YXSJCPY  created          |
|  Member actual   : 15         9   YXSJCPY2 created          |
|         name     : HOJPAR1    10  YXSJDEL  created          |
|                               11  YXSJEDT  created          |
|                               12  YXSJGDGL created          |
|                               13  YXSJISPF created          |
|                               14  YXSJGTYP created          |
|                                                             |
|                                                             |
+-------------------------------------------------------------+

If you press ENTER the program generates all template jobs a temporary library. Copying to the destination library will be done by the installation job.

//MYUSERV JOB (DEFAULT),'TEST PM INST',NOTIFY=&SYSUID    
//****************************************************** 
//* INSTALLATION PROCMAN HOST DATASETS                   
//****************************************************** 
//****************************************************** 
//* INSTALL PARM LIBRARY                                 
//****************************************************** 
//* DELETE LIBRARY                                       
//DELPARM  EXEC PGM=IDCAMS                               
//SYSPRINT DD  SYSOUT=*                                  
//SYSIN    DD  *                                         
 DEL MYUSER.PROCMAN.PARM                                 
 SET MAXCC=0                                             
/*                                                       
//* ALLOCATE LIBRARY                                     
//ALOCPARM EXEC PGM=IEFBR14,                             
//             COND=(04,LT)                              
//A01      DD  DSN=MYUSER.PROCMAN.PARM,                  
//             DISP=(,CATLG,DELETE),                     
//             UNIT=SYSDA,                               
//             SPACE=(TRK,(100,50,100),RLSE),            
//             LRECL=80,                                 
//             RECFM=FB                                  
//* RESTORE LIBRARY FROM INSTALLATION FILE               
//RECPARM  EXEC PGM=IKJEFT01,                            
//             COND=(04,LT)                              
//SYSPRINT DD  SYSOUT=*                                  
//SYSTSPRT DD  SYSOUT=*                                  
//SYSTSIN  DD  *                                         
 RECEIVE INDSN('HORIZONT.PROCMAN.V1R2.INSTALL(PARM)')    
 DATASET('MYUSER.PROCMAN.PARM') +                        
 RELEASE                                                 
/*                                                       
EsssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssN 
e Job-Control was saved USER.PROCMAN.V5R0.INSTALL(INSJOB1). Please check the  e 
e job control and enter SUBmit.                                               e 
DsssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssM                                      

After the members have been generated, you will see the installation job in Edit-Modus. Enter “SUBMIT” to start the Job. The Job should end with Severity Code 0. The two generated jobs are also stored in the installation library. Member names are INSJOB1 and INSJOB2.

The description of the syntax and the help function are now in a separate PDF manual. The reason for this is that this PDF manual is created directly from the windows online help.

The file "ProcMan - JCL Rules.PDF" and "ProcMan -JCL Rules.chm" are included in the delivery.

The online help is new and did not exist before.

It makes searching for specific content extremely easy and offers practical examples for many functions. These are constantly being added to.

The online help file is a compiled HTML file. Often there are problems with the display of subtopics in the browser program. For this reason, the online help file should be saved locally.

ProcMan zOS activities usually generate temporary files. After ProcMan has read these files, they can be deleted. The attached batch job deletes the data using IWSz control. As soon as a certain creation date is reached, these files are deleted.

Note! A backup, of these files, is not required.

/ //*%OPC SCAN                                                 
//MYJOB JOB (DEFAULT),'PM INSTALL',CLASS=A,NOTIFY=&SYSUID  
//***********************************************************
//***  DELETE PROCMAN TEMPORARY DATASET FROM PREVIOUS DAY    
//***********************************************************
//STEP1    EXEC PGM=ADRDSSU                                  
//SYSPRINT  DD SYSOUT=*                                      
//AUS1      DD DUMMY,DSN=NULLFILE,                           
//             DISP=(MOD,DELETE,DELETE),                     
//             DCB=(LRECL=80,BLKSIZE=0,RECFM=FB),            
//             SPACE=(TRK,(1,1),RLSE)                        
//SYSIN     DD *                                             
 DUMP DATASET(                          -                    
   BY(CREDT,LE,&OYYDDD)                -                     
//*%OPC BEGIN ACTION=NOSCAN                                  
   INCLUDE(                             -                    
           MY.PROCMAN.V5R1.WRK.H*.**             -        
          )                         -                        
             )                      -                        
     OUTDDNAME(AUS1)                -                        
     ALLDATA(*)                     -                        
     DELETE                         -                        
     ALLEXCP                        -                        
     OPTIMIZE(4)                                             
//*%OPC END   ACTION=NOSCAN                                                                                                                        

If problems occur in the SmartJCL part of ProcMan, it can be very helpful to pull all zOS files used by this ProcMan step and send them to HORIZONT via JIRA ticket.

//     EXPORT SYMLIST=*                             
//XMI  SET XMIFILE=MYUSER.XMIT                      
//DUMP SET DMPFILE=MYUSER.TRANSFER.DUMP             
//PID  SET PIDPREF=PROCMAN.PREF.H0001066.**         
//RUL  SET PXRULES=PROCMAN.PROD.RULES               
//DEL      EXEC PGM=IDCAMS                          
//SYSPRINT DD  SYSOUT=*                             
//SYSIN    DD *,SYMBOLS=EXECSYS                     
  DEL &XMIFILE                                      
  DEL &DMPFILE                                      
  SET MAXCC=0                                       
/*                                                  
//DASD     EXEC PGM=ADRDSSU,                        
//         REGION=32M                               
//SYSPRINT DD  SYSOUT=*                             
//BACKUP   DD  DSN=&DMPFILE.,                       
//             DISP=(NEW,CATLG,DELETE),             
//             SPACE=(TRK,(500,400),RLSE)           
//SYSIN    DD *,SYMBOLS=EXECSYS                     
 DUMP -                                             
   DATASET (INCLUDE(&PIDPREF.**, -                  
                    &PXRULES.) -                    
   OPTIMIZE(4) -                                    
   SHR -                                            
   ALLEXCP -                                        
   CANCELERROR -                                    
   SPHERE -                                         
   WAIT(0,0) -                                      
   OUTDDNAME(BACKUP)                                
//     IF  (DASD.RC EQ 0) THEN                      
//XMIT     EXEC PGM=IKJEFT01,                       
//         REGION=128M                              
//SYSPRINT DD  SYSOUT=*                             
//SYSTSPRT DD  SYSOUT=*                             
//SYSTSIN  DD *,SYMBOLS=EXECSYS                     
 XMIT X.X DS('&DMPFILE.') -                         
          OUTDS('&XMIFILE.')                        
//  ENDIF                                                                                      

The XMIT file must be transferred binary and added to the JIRA ticket.

The DB2 table CUSTOM_DATA can be filled using SQL statements. These can be generated with the PRCICUS batch program. Program can read data in CSV format or a FLAT file structure. The input data is described with DD EDEFCMDS. Furthermore, it must be described which data is stored in which column of the DB2 table.

DB2 Structure of CUSTOM_DATA

DATA_TYPE  VARCHAR(128) NOT NULL,
DATA_INT_1 INTEGER DEFAULT 0 NOT NULL,
DATA_INT_2 INTEGER DEFAULT 0 NOT NULL,
DATA_STR_1 VARCHAR(128) DEFAULT ' ' NOT NULL,
DATA_STR_2 VARCHAR(128) DEFAULT ' ' NOT NULL,
DATA_STR_3 VARCHAR(256) DEFAULT ' ' NOT NULL,
DATA_STR_4 VARCHAR(256) DEFAULT ' ' NOT NULL,
DATA_STR_5 VARCHAR(1024) DEFAULT ' ' NOT NULL,
DATA_STR_6 VARCHAR(2048) DEFAULT ' ' NOT NULL                             

Job-Control

//S010     EXEC PGM=PRCICUS, PARM='DO=PM2930.CUSTOM_DATA,MC=500'                                  
//* PROGRAM PARM 1: NAME OF DB2 TABLE                         
//* PROGRAM PARM 2: WRITE COMMIT AFTER EACH XXX SQL STATEMENT 
//CEEOUT   DD  SYSOUT=*                                       
//CEEDUMP  DD  SYSOUT=*                                       
//SYSPRINT DD  SYSOUT=*                                       
//SYSOUT   DD  SYSOUT=*                                       
//HOSOLOAD DD  DSN=&&PMFRMCO,DISP=(NEW,PASS,DELETE),                                      
//             RECFM=FB,LRECL=80,SPACE=(TRK,(100,100),RLSE)                             
//EDEFCMDS DD  *   
. . . . .                                                                                                                                  

The EXEC parameter ‘DO’ is used to specify the target table and the parameter ‘MC’ is used to specify the COMMIT frequency.

EDEFCMDS Example CSV

//EDEFCMDS DD  *                                               
IMPORT_FILE=P391C.PROCMAN.V5R1.USER.SYSIN(HOSEMICL);           
IMPORT_FILE_LRECL=80;                                          
IMPORT_TYP=CSV;                        /* FLAT OR CSV */       
IGNORE_FIRST_LINE=TRUE;                /* TRUE OF FALSE */     
SQL_TYP=INSERT;                        /* INSERT or DELETE  */
-                                      /* Default is INSERT */ 
-----------------------------------                            
-- PARAMETER FOR IMPORT_TYP CSV                                
-----------------------------------                            
CSV_DELIMITER=';';                                             
CSV_ENCLOSURE='"';                                             
CSV_COLUMNS_1=DATA_TYPE;                                       
CSV_COLUMNS_2=DATA_INT_1;                                      
CSV_COLUMNS_3=DATA_STR_1;                                      
CSV_COLUMNS_4=DATA_STR_2;                                      
CSV_KEY=CSV_COLUMNS_3;                                         
CSV_FILTER=CSV_COLUMNS_1,'FIRE';                               
END1BLOCK;                                                                                                                                                                                          

• IMPORT_FILE Name of Input file and Member name. Only PO datasets are supported.

• IMPORT_FILE_LRECL Record length of Input file. Following LRECL are supported. LRECL 80, 100, 120, 150, 200, 250, 300, 350, 400

• IMPORT_TYP CSV or FLAT Typ of IMPORT_FILE

• IGNORE_FIRST_LINE TRUE or FALSE If the 1st line contains headings.

• SQL_TYP INSERT or DELETE Which type of SQL should be written.

• CSV_DELIMITER Each 1 digit character. E.g. ; or , or !

• CSV_COLUMNS_n Column number of CSV source data and the target column in CUSTOM_DATA

• CSV_KEY Column number of CSV source data which must be unique. In the case of duplicate values, only the 1 entry is used.

Note! Each definition block must be terminated with END1BLOCK.

EDEFCMDS Example FLAT

//EDEFCMDS DD  *                                               
----------------------------------                          
IMPORT_FILE=P391C.PROCMAN.V5R1.USER.SYSIN(HOFLATFL);        
IMPORT_FILE_LRECL=80;                                       
IMPORT_TYP=FLAT;                       /* FLAT OR CSV */    
IGNORE_FIRST_LINE=TRUE;                /* TRUE OF FALSE */  
SQL_TYP=INSERT;                        /* INSERT or DELETE  */
-                                      /* Default is INSERT */
-----------------------------------                         
-- PARAMETER FOR IMPORT_TYP FLAT                            
-----------------------------------                         
FLAT_COLUMNS_1=DATA_TYPE,1:4;                               
FLAT_COLUMNS_2=DATA_INT_1,6:10;                             
FLAT_COLUMNS_3=DATA_STR_1,12:15;                            
FLAT_COLUMNS_4=DATA_STR_2,17:20;                            
FLAT_KEY=FLAT_COLUMNS_3;                                    
FLAT_FILTER=FLAT_COLUMNS_1,'HIRE';                          
END1BLOCK;                                                   

• IMPORT_FILE Name of Input file and Member name. Only PO datasets are supported.- IMPORT_FILE_LRECL Record length of Input file. Following LRECL are supported. LRECL 80, 100, 120, 150, 200, 250, 300, 350, 400

• IMPORT_TYP CSV or FLAT Typ of IMPORT_FILE

• IGNORE_FIRST_LINE TRUE or FALSE If the 1st line contains headings

• SQL_TYP INSERT or DELETE Which type of SQL should be written.

• FLAT_COLUMNS_n Column number of FLAT source data and the target column in CUSTOM_DATA

• FLAT_KEY Column number of FLAT source data which must be unique. In the case of nn duplicate values, only the 1 entry is used.

• FLAT_FILTER Column number of FLAT source data and search value.

The DB2 table FORMCONT can be filled using SQL statements. These can be generated with the PRCIFRM batch program. The input data is described with DD EDEFCMDS.

DB2 Structure of FORMCONT

Job-Control

The EXEC parameter ‘DO’ is used to specify the target table and the parameter ‘MC’ is used to specify the COMMIT frequency.

EDEFCMDS Example

• Parameter 1 Name of the Input file (Only PO datasets are supported)

• Parameter 2 Name of the Input member name.

• Parameter 3 Record length of Input file. Following LRECL are supported. LRECL 80, 100, 120, 150, 200, 250, 300, 350, 400

• Parameter 4 Record format e.g. FB

• Parameter 5 Statement Typ. E.g. JOB, EXEC or DD

• Parameter 6 Name of the Web Form Field

• Parameter 7 Name of the Web Form

• Parameter 8 Label start position in the input data

• Parameter 9 Label length in the input data

• Parameter 10 Value start position in the input data

• Parameter 11 Value length in the input data

• Parameter 12 User start position in the input data (Optional)

• Parameter 13 User length in the input data (Optional)

With the ProcMan zOS installation, an administration dialog is also installed. With this dialog, the ProcMan VSAM databases can be viewed and changed, as well as a syntax check of the Rules can be performed. For Rule syntax check, the included Edit macro "RULE" can be used.

In the installed CLIST / REXX library, execute the member PRCX with "EX" (execute).

Start dialog

EDIT              SYSH.PROCMAN.VxRx.REXX                Row 0000001 of 0000031 
 Command ===>                                                  Scroll ===> CSR  
            Name     Prompt       Size   Created          Changed          ID   
 _________ CHCKOPCS                 39  2016/08/30  2016/08/30 11:56:00  HORIZON
 _________ HUKXQS01                 54  2016/08/30  2016/08/30 11:56:00  HORIZON
 _________ PMIIPARM                  2  2016/10/27  2016/10/27 08:26:29  HORIZON
 _________ PRCECHEK                724  2017/02/22  2017/03/02 15:35:42  HORIZON
 _________ PRCEDATA                 15  2017/02/22  2017/02/22 08:37:00  HORIZON
 _________ PRCEEHOR                843  2017/02/22  2017/02/22 08:37:00  HORIZON
 _________ PRCEJREF                 21  2017/02/22  2017/02/22 08:37:00  HORIZON
 _________ PRCERLOG                579  2017/02/22  2017/02/22 08:37:00  HORIZON
 _________ PRCETEND                 13  2017/02/22  2017/02/22 08:37:00  HORIZON
 _________ PRCETEXT                 12  2017/02/22  2017/02/22 08:37:00  HORIZON
 _________ PRCEVINI                 13  2017/02/22  2017/02/22 08:37:00  HORIZON
 _________ PRCRULED                                                             
 ex_______ PRCX                     35  2017/02/22  2017/02/22 08:37:00  HORIZON
 _________ PRCXCDIA                 32  2017/02/22  2017/02/22 08:37:00  HORIZON

The following dialog appears:

--------------------------  ProcMan Rule Test dialog --------------------------
Please select ===>                                                             
                                                                               
  S   Syntax Check of Rule member                             USERID  -MYUSER  
  C   Display check tables                                    System  -SYSA    
  X   End                                                     Time    -10:36   
                                                              Date    -31/05/21
                                                              Program -REXX    
                                                              Build   -VxRx    
Commands: END for end of the dialog.                                           

Check Rules via dialog

Rule syntax checking, checks the correct spelling of Rule parameters, setting commas and setting semicolon at the end of the Rule. Furthermore, the Rules numbering is displayed with “ISPF NOTE” lines.

PRCPMAIN -----------------  ProcMan Rule Test dialog --------------------------
Please select ===> S                                                            
                                                                               
  S   Syntax Check of rule member                             USERID  -USERID   
      For new rules (V5) only                                 System  -SYSA    
  C   Display check tables                                    Date    -21/05/27
  X   End                                                     Time    -15:02   
                                                              Program -REXX    
                                                              Build   -V5R0    
                                                                               
Commands: END for end of the dialog.                                           

After entering “S”, the dialog for entering the library and the member is displayed.

--------------------------- ProcMan Rule Test dialog --------------------------
                                                                               
Please select ===>                                             Scroll ===> CSR 
                                                                               
Enter the library and the Rule member name.                                    
Library: MY.RULE.LIBRARY                              Member: MYRULE                 
                                                                             
                                                                               
After entering library/member the content will shown with error messages.      

After entering Rule library name and member name have been specified, the member will be displayed in ISPF-Editor.

E EDIT       DATA.PRX.DATA.QS.RULES(A#BA#001) - 01.12        Columns 00001 00080 
Command ===> CHECK                                               Scroll ===> CSR  
****** ********************************* Top of Data ****************************
000001 ========================================================================        
000002 = AAAA N   N AAAA L   Y   Y  SSS EEEE                                  =        
000003 = A  A NN  N A  A L    Y Y  S    E                                     =        
000004 = A  A N N N A  A L     Y    SS  EEE                                   =        
000005 = AAAA N  NN AAAA L     Y      S E                                     =        
000006 = A  A N   N A  A LLLLL Y   SSS  EEEE                                  =        
000007 ========================================================================        
000008 define #log=true;                                                               
000009 --define #log_jcl=true;                                                         
000010 define #log_var='AUTO';                                                         
000011 define #cache_table='AUTO';                                                     
000012 define #cache_never=[];                                                         
000013 --------------------------------------------------                              
000014 -- Read all jcl statements and execute                                          
000015 --------------------------------------------------                              
000016 FOREACH(JCLSTMT() as &VAR:JCLS);                                                
000017   CALL USEJCLSTMT(&VAR:JCLS);                                                   
000018 --------------------------------------------------                              
000019 WILDCARD ?%;                                                                    
000020 CALL                                                                            
000021 FILTER                                                                          
000022   STMT='JOB'                                                                    
000023 EXEC                                                                            
000024   SETFORM('FRM_JCK_JOB_BA')                                                     
000025        /* Jobname 1-3 */                                                        
000026 EXEC                                                                            
000027   SETFIELD('JOBN1',SUBSTR(JOBNAME(),1,4))                                       
000028        /* Jobname 4-8 */                                                        
000029 EXEC                                                                            
000030   SETFIELD('JOBN2',SUBSTR(JOBNAME(),5,4))                                       
000031        /* Account */                                                            
000032 EXEC                                                                            
000033   SETFIELD('#PP01',SUBPARM('#PP01',1))                                          
000034        /* Programers Name */                                                    
000035 EXEC                                                                            
000036   SETFIELD('#PP02',PARM('#PP02'))                                               
000037 FILTER                                                                          
000038   FIELD='#PP02'                                                                 
000039 EXEC                                                                            
000040   SETATTR('must','N')                                                           
000041        /* Put job in the call list */                                           
000042 EXEC                                                                            
000043   SETFIELD('ONCALL','N');                                                       
000044 -                                                                               
000045 CALL                                                                            
000046 FILTER                                                                          
000047   STMT='JOB',                                                                   
000048   TEST=HOTYPE() EQ 'CHANGE',                                                    
000049     +----------------------------------------------------+              
000050     ! Enter CHECK at command line to start syntax check. !              
000051     +----------------------------------------------------+              
After typing “CHECK” in command line the Rule member will be checked.

EDIT       DATA.PRX.DATA.QS.RULES(A#BA#001) - 01.12       CHECK SUCCESSFUL, RC=0
Command ===>                                                     Scroll ===> CSR 
****** ********************************* Top of Data ****************************
==MSG> MESSAGE SUMMARY. Rules=0560  Errors=0000 Warnings=0000 Total=0000             
==MSG> Included rules.  Rules=0391  Errors=0000 Warnings=0000 Total=0000                           
==MSG> Error Message                                                                  
==MSG> -----------------------------------------------         
000001  ========================================================================       
000002 = AAAA N   N AAAA L   Y   Y  SSS EEEE                                  =       
000003 = A  A NN  N A  A L    Y Y  S    E                                     =       
000004 = A  A N N N A  A L     Y    SS  EEE                                   =       
000005 = AAAA N  NN AAAA L     Y      S E                                     =       
000006 = A  A N   N A  A LLLLL Y   SSS  EEEE                                  =       
000007 ========================================================================       
000008 define #log=true;                                                              
000009 --define #log_jcl=true;                                                        
000010 define #log_var='AUTO';                                                        
000011 define #cache_table='AUTO';                                                    
000012 define #cache_never=[];                                                        
000013 --------------------------------------------------                             
000014 -- Read all jcl statements and execute                                         
000015 --------------------------------------------------                             
000016 FOREACH(JCLSTMT() as &VAR:JCLS);                                               
=NOTE= Rule 1                                                                         
000017   CALL USEJCLSTMT(&VAR:JCLS);                                                  
000018 --------------------------------------------------                             
000019 WILDCARD ?%;                                                                   
=NOTE= Rule 2                                                                         
000020 CALL                                                                         
000021 FILTER                                                  
000022   STMT='JOB'                                                                   
000023 EXEC                                                                           
000024   SETFORM('FRM_JCK_JOB_BA')                                                    
000025        /* Jobname 1-3 */                                                       
000026 EXEC                                                                           
000027   SETFIELD('JOBN1',SUBSTR(JOBNAME(),1,4))                                      
000028        /* Jobname 4-8 */                                                       
000029 EXEC                                                                           
000030   SETFIELD('JOBN2',SUBSTR(JOBNAME(),5,4))                                      
000031        /* Account */                                                           
000032 EXEC                                                                           
000033   SETFIELD('#PP01',SUBPARM('#PP01',1))                                         
000034        /* Programers Name */                                                   
000035 EXEC                                                                           
000036   SETFIELD('#PP02',PARM('#PP02'))                                              
000037 FILTER                                                                         
000038   FIELD='#PP02'                                                                
000039 EXEC                                                                           
000040   SETATTR('must','N')                                                          
000041        /* Put job in the call list */                                          
000042 EXEC                                                                           
000043   SETFIELD('ONCALL','N');                                                      
000044 -                                                                              
=NOTE= Rule 3                                                                         
000045 CALL                                                                           
000046 FILTER                                                                         

ISREDDE2   DATA.PRX.DATA.QS.RULES(A#BA#004) - 01.08        ERRORS OCCURRED, RC=8 
Command ===>                                                      Scroll ===> CSR  
****** ********************************* Top of Data ****************************
==MSG> MESSAGE SUMMARY. Rules=0025  Errors=0001 Warnings=0000 Total=0001               
==MSG> Error Message                                                                   
==MSG> ----------------------------------------------------------------------          
==MSG> Line 33 PRXE0051 UNKNOWN FUNCTION CALLED: SBSTR                                 
000001 ========================================================================        
000002 = Migration of Rule member with new rule syntax                        =        
000003 ========================================================================        
000004 ========================================================================        
000005 = AAAA N   N AAAA L   Y   Y  SSS EEEE                                  =        
000006 = A  A NN  N A  A L    Y Y  S    E                                     =        
000007 = A  A N N N A  A L     Y    SS  EEE                                   =        
000008 = AAAA N  NN AAAA L     Y      S E                                     =        
000009 = A  A N   N A  A LLLLL Y   SSS  EEEE                                  =        
000010 ========================================================================        
000011 define #log=true;                                                               
000012 --define #log_jcl=true;                                                         
000013 define #log_var='AUTO';                                                         
000014 define #cache_table='AUTO';                                                     
000015 define #cache_never=[];                                                         
000016 --------------------------------------------------                              
000017 -- Read all jcl statements and execute                                          
000018 --------------------------------------------------                              
000019 FOREACH(JCLSTMT() as &VAR:JCLS);                                                
=NOTE= Rule 1                                                                          
000020   CALL USEJCLSTMT(&VAR:JCLS);                                                   
000021 --------------------------------------------------                              
000022 WILDCARD ?%;                                                                    
=NOTE= Rule 2                                                                          
000023 CALL                                                                            
000024 FILTER                                                                          
000025   STMT='JOB'                                                                    
000026 EXEC                                                                            
000027   SETFORM('FRM_JCK_JOB_BA')                                                     
000028        /* Jobname 1-3 */                                                        
000029 EXEC                                                                            
000030   SETFIELD('JOBN1',SUBSTR(JOBNAME(),1,3))                                       
000031        /* Jobname 4-8 */                                                        
000032 EXEC                                                                            
000033   SETFIELD('JOBN2',SBSTR(JOBNAME(),4,5))                                        
==MSG> Line 33 PRXE0051 UNKNOWN FUNCTION CALLED: SBSTR                                 
000034        /* Account */                                                            
000035 EXEC                                                                            
000036   SETFIELD('#PP01',SUBPARM('#PP01',1))                                          
000037        /* Programers Name */                                                    
000038 EXEC                                                                            
000039   SETFIELD('#PP02',PARM('#PP02'))                                               
000040 FILTER                                                                          
000041   FIELD='#PP02'                                                                 
000042 EXEC                                                                            
000043   SETATTR('must','N')                                                           
000044        /* Put job in the call list */  

Display check tables

If Rules using the table function, the corresponding data must be loaded into a VSAM file with a management job. The contents of this VSAM file can be displayed with the dialog.

PRCPMAIN -----------------  ProcMan Rule Test dialog --------------------------
Please select ===> C                                                            
                                                                               
  S   Syntax Check of rule member                             USERID  -USERID   
      For new rules (V5) only                                 System  -SYSA    
  C   Display check tables                                    Date    -21/05/27
  X   End                                                     Time    -15:02   
                                                              Program -REXX    
                                                              Build   -V5R0    
                                                                               
                                           
Commands: END for end of the dialog.                                           

After entering “C”, the dialog for entering the name of the VSAM dataset is displayed.

- PRCPDCH2 -------------------- ProcMan check table -----------------------------
                                                                               
Please select ===>                                             Scroll ===> CSR 
                                                                               
Commands: R Refresh CAN Quit                                                   
                                                                               
Enter name of Check VSAM Dataset                                               
                                                                               
VSAM Dataset: HLQ.PC110.CHECK.VSAM                         '?' for all values!                                                                                
                                                                               

After entering the file name and ENTER an overview of loaded tables is displayed.

------------------------- ProcMan Overview check table --------- Row 1 from 6 
Please select ===>                                             Scroll ===> CSR 
                                                                               
Commands: CAN End without save END End without save                            
LineCmds: S Show content                                                       
                                                                               
  *                                                                            
  EQ                                                                           
  Table    Record Creation date/time                                           
  -------- ------ ------------------                                           
S HOJJACCT 22     2017-12-08  09:12                                            
  HOSB93D1 1670   2017-12-08  09:12                                            
  HOSB93D2 57     2017-12-08  09:12                                            
  HOJB93D3 108    2017-12-08  09:12                                            
  HOSB93D4 57     2017-12-08  09:12                                            
  HOSB93D5 171    2017-12-08  09:12                                            
******************************* Bottom of data ********************************

By entering “S” the data can be displayed in more detail

- ------------------------- ProcMan check table HOJJACCT --------- Row 2 from 24 
Please select ===>                                             Scroll ===> CSR 
Commands: CAN END End without save  2 3 4 5 6 7 show other columns             
          UPDATE Switch on/off Update Modus                                    
LineCmds: S Show content                                                       
Key: SVJJACCT Gen: 0 Search DTKEY: *                                         EQ
                           *                 *                 *               
                           EQ                EQ                EQ              
  Key   Gen   DTKEY        DTDAT1            DTDAT2            DTDAT3          
  ------------------------ ----------------- ----------------- ----------------
S HOJJACCT0FTP             FTP               TP                FILETRANSFER    
  HOJJACCT0F00             F00               00                ADMINISTRATION   
  HOJJACCT0F01             F01               01                KANKENVERSICHERUNG 
  HOJJACCT0F02             F02               02                LEBENSVERSICHERUNG 
  HOJJACCT0F03             F03               03                FEUERVERSICHERUNG  
  HOJJACCT0F04             F04               04                MARKETING    
  HOJJACCT0F05             F05               05                SCHADENSGULIERUNG         
  HOJJACCT0F06             F06               06                FINANZBUCHHALTUNG 
  HOJJACCT0F07             F07               07                MIETE           
  HOJJACCT0F08             F08               08                DARLEHEN        
  HOJJACCT0F09             F09               09                ALLGEMEIN       
  HOJJACCT0F10             F10               10                TEXTMANAGEMENT  
  HOJJACCT0F11             F11               11                OPERATION      
  HOJJACCT0F12             F12               12                EINKAUF   
  HOJJACCT0F13             F13               13                DATAWAREHOUSE   
  HOJJACCT0F14             F14               14                REVISION        
  HOJJACCT0F15             F15               15                DRITTSYSTEME    
  HOJJACCT0F16             F16               16                ORGANISATION      
  HOJJACCT0F17             F17               17                UNFALLVERSICHERUNG 
  HOJJACCT0F43             F43               43                SACHVERSICHERUNG  
  HOJJACCT0F45             F45               45                SCHADENSREGEULIER      
  HOJJACCT0F83             F83               83                ADHOC           
******************************* Bottom of data ******************************** 

Each data has the length of 50 bytes. There are 7 data fields. To see the data in full length, enter a “S” in front of the line.

-------------------------  Detail record table HOJJACCT -----------------------
Command ===>                                                   Scroll ===> HALF
                                                                               
DTKEY                       HOJJACCT0FTP                                       
DTGENER                     0              0=full qualified  1=generic value   
DTDAT1                      FTP                                                
DTDAT2                      TP                                                 
DTDAT3                      FILETRANSFER                                       
DTDAT4                                                                         
DTDAT5                                                                         
DTDAT6                                                                         
DTDAT7                                                               

DTDAT1 to DTDAT7 is not a clear header. With administration run new header, for each column can be set.

The ProcMan JCL rule set offers the option of using check tables. These check tables are saved in a VSAM file. This VSAM file is recreated cyclically so that the latest data is saved. This usually happens every 24 hours when the online ProcMan is no longer being used.

Job-Control

//S010     EXEC PGM=PRCICHK,REGION=0M                            
//CEEDUMP  DD  SYSOUT=*                                          
//SYSOUT   DD  SYSOUT=*                                          
//SYSPRINT DD  SYSOUT=*                                          
//HOSVLOAD DD  DSN=&&PMLOAD,DISP=(NEW,PASS,DELETE),              
//             RECFM=FB,LRECL=400,SPACE=(TRK,(500,250),RLSE)     
//EDEFCMDS DD  *                                                 
DEPART;   P391C.PROCMAN.V5R1.USER.SYSIN; HOSAGB01; 80; FB; +     
     1;  1;

EDEFCMDS description

• Parameter 1 Name of the check table

• Parameter 2 Name of the Input file (Only PO datasets are supported)

• Parameter 3 Name of the Input member name.

• Parameter 4 Record length of Input file. Following LRECL are supported. LRECL 80, 100, 120, 150, ZZ 200, 250, 300, 350, 400

• Parameter 5 Record format e.g. FB

• Parameter 6 LABEL Which data for the label. E.g.

  • 1; 1. Column of input data

  • 1,2; 1. and 2. Column of input data

  • (1:30); Start in position 1 with length of 30

  • (1:15;24:3) Start in position 1 with length of 15 and start in position 24 with length of 3

• Parameter 7 VALUE Which data for the value. E.g. -1,4,3,2

  • 1. Column of input data for VSAM DATA1

  • 4. Column of input data for VSAM DATA2

  • 3. Column of input data for VSAM DATA3

  • 2. Column of input data for VSAM DATA4

    • 1(53:3),2(48:4),3(57:48);

    • position 53 length of 3 of input data for VSAM DATA1

    • position 48 length of 4 of input data for VSAM DATA2

    • position 57 length of 48 of input data for VSAM DATA3

EDEFTITL description (new title will be shown with the ISPF dialog)

• Parameter 1 Name of the check table

• Parameter 2 Column number of check table

• Parameter 3 New title of column ( instead DATA1, DATA2…..)

Accounts in ProcMan store information about users. They contain login information (user name and password) as well as additional optional information (description, e-mail, phone number, etc.) about the user.

Accounts can be defined in a way that ProcMan verifies the user name and password at login, or the database server verifies the user name and password at login, or they can be imported from an LDAP server, which also verifies the user name and password at login.

Beware that the user names are unique in the whole ProcMan system. There cannot be defined an account with some user name in one client and another account with the same user name in another client. If different accounts are meant then their user name must be unique. If the same account is meant then the best praxis is to define it in an ancestor client of all clients where it shall be used.

Initially, there is an account defined in the ProcMan, which is a master administrator (has assigned the role ADMIN in the client ROOT). Its user name is admin and its password is also admin. It is strongly recommended to change the password of this master administrator after the installation. Alternatively another master administrator can be defined and the admin account can be deleted then.

The ProcMan administration dialog menu is divided into two main sections: Definitions and Tools (see picture below).

The section 'Definitions' contains items which represent objects in ProcMan (Clients, Roles, Accounts, Calendars and Search areas) and also relationships among them (Timezone assignment, Role assignment and Calendar assignment). The submenu 'Processes' contains items which represent parts of process definitions in ProcMan (Actions, Global Definitions and Process Definitions).

The section "Tools" offers useful features to help administer the ProcMan (Deleted Processes, Encryption, Log Files Administration and Savepoints).

Clicking on an item in the administration dialog menu starts the appropriate dialog.

Clients

Clients are the most general objects in ProcMan. Logically they can represent something in a real world, for example customers, organization units, etc. Technically, they are containers of other objects definitions and process instances (processes in the Work list). Clients in ProcMan are organized hierarchically. In the top of the clients hierarchy is always the client ROOT, which is the ancestor of all other clients. Each client can have any number of children clients. The client hierarchy in ProcMan can be arbitrarily deep. The definition of other objects like roles, user accounts and process definitions as well as assignments of roles to user accounts is being done in clients. Each definition of such objects and each role assignment in a client, are only visible and effective in the client itself and in its descendant clients. Process instances (processes in the plant list) that are assigned to a client are only visible in the respective client itself.

Clients list

Click Clients to start the client administration dialog. Beware that you can administrate in this dialog only descendants’ clients. Sample: you are logged in client ROOT then you can administrate the descendants of client ROOT.

After the dialog has been started, the list of already defined descendant clients of the logged in client is displayed (see picture below). If the current client has no descendants a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the client definition forms for new and edited clients, by selecting another function from the ProcMan menu. The last entries are discarded.

Creating a new client

A new client can be defined by clicking the New button in the clients list form. After that a form with the client definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new client is created and appears in the clients list. By clicking the Cancel button the dialog returns to the clients list without creating a new client.

The field Name has to be filled with the name of the new client. The name of the client can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

In the field Parent the parent client of the new client has to be selected.

The field Description can be filled with a textual description of the new client. It is a free text, which can contain any printable characters. It also can be left empty.

With the field Calendar you assign a calendar to the client. The calendar specifies which days shall be handled as free days for this client (e.g. every Sunday, Christmas days, etc.). This can be relevant when the user makes date entries in the general process data. Calendars can be defined in the Calendar administration dialog. If the calendar which shall be used by the new client is not defined yet, this field can be left empty. It can be set later by editing the client or in the Calendar assignment administration dialog. If there is no calendar specified for the client then all days are handled as working days.

The check-box Allow to select this client on login specifies whether the users can select this client for to login in. Beware that this option is only a helper to reduce the list of clients displayed at the login time. If you disallow all clients where a user would normally be able to login, the effect of this option will be switched off and the user will be able to select from the complete list of clients in which he is authorized to login.

The check-box Enabled specifies whether the client can be used in ProcMan or not. If a client is not enabled, all its descendants’ clients are also disabled (even if they are set to be enabled).

Editing a client

Select a client from clients list form (checking the radio-button at the beginning of the table row) and click the Edit button. Alternatively a client definition can be edited also by clicking on the client name in the table of the clients list form. After that a form with the client definition fields appears. This form is the same like the form for a new client except, that the field Parent is read-only and cannot be changed.

Deleting a client

Select a client from clients list form (checking the radio-button at the beginning of the table row) and click the Delete button in the clients list form. Beware that this action also deletes all descendant clients and all processes for this clients. To avoid deleting clients by mistake only disabled clients can be deleted. An alternative to the deletion of a client is to disable the client.

Adding a client into the Transfer Case

Select a client from the client list form (checking the radio-button at the beginning of the table row) and click the Into Transfer Case button in the client list form. After the selected client has been added into the Transfer Case you can add another client or another objects into the Transfer Case or continue with other administration work. For more information about the Transfer Case see the description of the Transfer Case tool in this document.

Roles

Roles are there to group individual user and to give them certain rights in ProcMan. Often defined roles are developer, tester, admin, approver, production planner etc.

Roles also manage the set of functions which can be started by a user. Such functions are for example administration, creating a process, or starting a specific process activity. Therefore each user must be assigned to minimum one role.

The roles in ProcMan are organized hierarchically. Any role can be a root role (with no parent roles) or a child role of another role. Any role can have an arbitrary count of children roles. The role hierarchy in ProcMan can be arbitrarily deep. The semantic of the role hierarchy is, that if a user has a role assigned, he is implicitly authorized also in all ancestor roles of the assigned role, but in no descendant role of the assigned role (except that a descendant role is assigned explicitly to the user).

However, the hierarchical organization of roles needs not to be used if there is no concrete need for it. In this case all roles can be defined without parent and children.

Beware that the role names are unique in the whole ProcMan system. There cannot be defined a role with some name in one client and another role with the same name in another client. If different roles are meant then their name must be unique. If the same role is meant then the best praxis is to define it in an ancestor client of all clients where it shall be used.

There is a special role initially named ADMIN defined in the client ROOT. This role allows the users to which it is assigned to administrate ProcMan and recall/delete processes in the work list (if administrators are authorized to do this). This role cannot be deleted or disabled, but the name and/or description of this role can be changed in the roles dialog.

Roles list

By clicking on the Roles menu item the role administration dialog is being started. Beware that this dialog can only administrate the roles defined in the client, in which the user is currently logged in, and in the descendant clients of this client.

After the dialog has been started, the list of already defined roles is displayed (see picture below). If there are no roles a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the role definition forms for new and edited roles, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Creating a new role

A new role can be defined by clicking the New button in the roles list form. After that a form with the role definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new role is created and appears in the roles list. By clicking the Cancel button the dialog returns to the roles list without creating a new role.

In the field Client the client in which the role will be created has to be selected.

The field Name has to be filled with the name of the new role. The name of the role can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

In the field Parent the parent role of the new role has to be selected or it can be left empty.

The field Description can be filled with a textual description of the new role. It is a free text, which can contain any printable characters. It also can be left empty.

The check-box Process Administration, if checked, specifies that users to which the role is assigned can recall/delete processes in the work list (if administrators are authorized to do this), but they cannot administrate ProcMan (they do not even see the administration dialog menu).Though this option can be checked for any role, it is recommended not to check it for roles dedicated for creating processes and starting activities. Better praxis is to define special roles having this option checked, which allows better control of who is allowed to administrate processes.

The check-box User Administration, if checked, specifies that users to which the role is assigned have limited administrator permissions, allowing them to administrate accounts, timezone assignments and role assignments. Users having this role will have an administration dialog menu, limited to this these functions. Though this option can be checked for any role, it is recommended not to check it for roles dedicated for creating processes and starting activities. Better praxis is to define special roles having this option checked, which allows better control of who is allowed to administrate users.

The check-box Revision, if checked, enables for users to which the role is assigned a special menu item Revision – Deleted Processes. When the menu item is clicked by a user, a list of deleted processes is displayed to the user. The list is similar to the Deleted Processes tool for the administrators (described later in this documentation), except that the Delete button is missing. Though this option can be checked for any role, it is recommended not to check it for roles dedicated for creating processes and starting activities. Better praxis is to define special roles having this option checked, which allows better control of who is allowed to view the deleted processes.

The check-box Enabled specifies whether the role can be used in ProcMan or not. If a role is not enabled it behaves like if the role would not be defined at all. Moreover if a role has descendant roles and it is not enabled, the descendants are disabled as well, even if they are set to be enabled.

Editing a role

A role definition can be edited by selecting it in the roles list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the roles list form. Alternatively a role definition can be edited also by clicking on the role name in the table of the roles list form. After that a form with the role definition fields appears. This form is the same like the form for a new role except, that the fields Client and Parent are read-only and cannot be changed.

Deleting roles

One or more roles can be deleted by selecting them in the roles list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the roles list form. Beware that with the roles also all descendant roles are deleted. An alternative to the delete of a role is to disable it. In this case neither the role, nor its descendant roles are deleted.

Adding roles into the Transfer Case

Select one or more roles from the roles list form (checking the check-button at the beginning of the table rows) and click the Into Transfer Case button in the roles list form. After the selected roles have been added into the Transfer Case you can add another roles or another objects into the Transfer Case or continue with other administration work. For more information about the Transfer Case see the description of the Transfer Case tool in this document.

By clicking on the Accounts menu item the account administration dialog is being started. Beware that this dialog can only administrate the accounts defined in the client, in which the user starting it is currently logged in, and in the descendant clients of this client.

After the dialog has been started, the list of already defined accounts is displayed (see picture below). If there are no accounts a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the account definition forms for new and edited accounts, for changing password or in the LDAP import forms, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Alternatively to creating the accounts in the ProcMan, accounts can also be imported from an LDAP server. For such accounts the user name and password are verified by the LDAP server instead of by ProcMan at login.

ProcMan supports also importing accounts from more than one LDAP servers. In this case for each account are the user name and password verified by the LDAP server from which the account has been imported.

LDAP import form

Accounts can be imported from LDAP servers by clicking the LDAP button in the accounts list form. After that a LDAP Import form appears (see picture below).

Beware that the object structure on the LDAP server strongly depends on the type of the server (RACF, Active Directory, OpenLDAP etc.) and on the organization structure of the company mirrored in the object structure on the LDAP server. Therefore the proper filling of this form must be done hand-in-hand with the administrator of the LDAP server, which should know the proper distinguished name (shortly dn) and the object class of the account objects in LDAP as well as the names of the from the LDAP server returned attributes.

After filling the fields in this form and clicking the OK button the dialog lists all users found on the LDAP server matching the specified criteria in the LDAP import – User selection form. By clicking the Cancel button the dialog returns to the accounts list.

If the accounts shall be imported from a LDAP server from which an successful import already has been done before, by clicking the Use known LDAP button and selecting the LDAP server from the list on the following form, the LDAP import form will be filled with the values used before without a need to type them again.

The field LDAP host has to be filled with the IP address or the DNS name of the LDAP server. Alternatively the LDAP server can be specified in the URL format ldap[s]://<host>[:<port>] here (e.g. ldaps://ldap.my_company.com:390). For encrypted secure LDAP connection the LDAP server can be specified only in the URL format with ldaps as service.

The field LDAP port has to be filled with the port number of the LDAP service on the LDAP server. In the case that the LDAP server have been specified in the URL format in the field LDAP host, the port number specified here is ignored.

The field Bind password has to be filled with the password of the user specified in the Bind dn field. Beware that this password is used only for one LDAP import. It is nowhere stored in ProcMan. So it has to be typed for every new import again and again, even if the form has been filled using a known LDAP.

The field Search dn has to be filled with the distinguished name identifying where to search for the user objects in the object structure on the LDAP server.

The field User dn identifier has to be filled with the name of the attribute in which the LDAP server returns the user distinguished names after applying Search dn and Filter.

The field User identifier has to be filled with the name of the attribute in which the LDAP server returns the user name after applying search for a particular user distinguished name.

The check-box User names are case sensitive specifies whether the imported user names shall be handled as case sensitive or insensitive. If it is checked the names will always to be typed exactly like they have been imported from the LDAP server at login. Otherwise any alphabetic letter in the user names can be typed as a capital or a small letter at login.

The field Show only users matching filter has to be filled with a pattern string specifying, that the user name of the users returned by the LDAP server must match this pattern to be shown in the users list in the following LDAP import – User selection form. The pattern string can contain wildcards: asterisk (*) and question mark (?). Asterisk means any string even an empty. Question mark means any character. If asterisk or question mark are not meant as wildcards but characters appearing in the user names, they must be escaped with a backslash (\ ) like this: \* ,\? Also if backslash is meant as a character appearing in the user names it must be escaped like this: \\.

In the field Description identifier the name of the attribute in which the LDAP server returns the user description can be filled. This field can be left empty but no user description will be imported in this case.

In the field Company identifier the name of the attribute in which the LDAP server returns the name of the company can be filled. This field can be left empty but no company will be imported in this case.

In the field Telephone identifier the name of the attribute in which the LDAP server returns the phone number of the user can be filled. This field can be left empty but no phone number will be imported in this case.

In the field Mobile identifier the name of the attribute in which the LDAP server returns the mobile-phone number of the user can be filled. This field can be left empty but no mobile-phone number will be imported in this case.

In the field E-mail identifier the name of the attribute in which the LDAP server returns the E-mail address of the user can be filled. This field can be left empty but no E-mail address will be imported in this case.

The check-box Users are allowed to change their passwords specifies whether the users authenticated by the LDAP server can change their passwords or not.

In the selection-box LDAP server/backend type the type of the LDAP server/backend has to be selected. It is displayed only if the check-box Users are allowed to change their passwords is checked. Currently only RACF or other can be selected here. To select a proper type here is important because changing of a password via LDAP works different for RACF and for other LDAP servers/backends.

In the field Password identifier the name of the password attribute in the LDAP structure for a user has to be specified. It is displayed only if the check-box Users are allowed to change their passwords is checked and if the type other is selected in the selection-box LDAP server/backend type. In this case a non-empty attribute name has to be specified here.

LDAP import – User selection form

After filling the fields in the LDAP import form and clicking the OK button the dialog lists all users found on the LDAP server matching the specified criteria in the LDAP import – User selection form (see picture below).

By clicking the Cancel button the dialog returns to the accounts list without importing any new accounts.

In the field Client select the client in which the accounts shall be imported.

The users which have been found on the LDAP server are listed in a table. Users which shall be imported can be selected by checking the check-box in the first column of the table rows. Users which are not selected are ignored by the import. At the opening of this form only users which are unknown in ProcMan (they have no accounts yet) are selected. However the initial selection of the users can be freely changed. If a user which is already known in ProcMan is selected, the import will actualize the account from LDAP (replace the description, company, e-mail etc. with the current one).

By clicking the OK button the import is started and for the selected users the ProcMan accounts are being created or actualized in the specified client. After the import has been finished the dialog returns to the accounts list.

Known LDAPs form

After clicking the Use known LDAP button in the LDAP import form the dialog opens the Known LDAPs form (see picture below).

By clicking the Cancel button the dialog returns to the LDAP import form.

When a LDAP system is selected by checking the check-box in the first column of the row of the LDAP system and clicking the OK button the dialog returns to the LDAP import form and fills it with the values stored for the selected LDAP system. Alternatively to click on the IP address / DNS name of the host in the table of known LDAPs has the same effect.

This form also allows to delete LDAP systems from the table of known LDAPs by selecting on or more LDAP systems and clicking the Delete button. Only LDAP systems which are currently not in use by any account in ProcMan can be deleted.

Authentication by a z/OS system is an alternative way to verify the user and password on login in ProcMan. By this method, the user and password are sent to and verified on the z/OS system using HORIZONT z/OS utilities.

z/OS system configuration list

z/OS system configurations can be managed in the dialog started by clicking the z/OS button in the accounts list form. After that a list of already configured z/OS systems is displayed (see picture below).

By clicking the Cancel button the dialog returns to the accounts list.

Creating a new z/OS system configuration

A new z/OS system configuration can be defined by clicking the New button in the accounts list form. After that, a form with the z/OS system configuration definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new configuration is created and appears in the z/OS system configuration list. By clicking the Cancel button the dialog returns to the z/OS system configuration list without creating a new configuration.

The field Name has to be filled with a unique name of the configuration. The name of the configuration can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form, the name is converted into uppercase. The name can be selected in the z/OS Login field of the account form or in the change password form to specify, that this configuration shall be used for the authentication of the account.

The field Server (IP or DNS) has to be filled with the IP address or the DNS name of the z/OS system.

The field Port has to be filled with the port on which the HORIZONT z/OS utilities service (also known as HORJLST) on the z/OS system is waiting for connections.

The field Member has to be filled with the member name of the HORIZONT z/OS utilities handler (also known as HORJSRV) on the z/OS system. After submitting the form, the name is converted into uppercase.

Editing a z/OS system configuration

A z/OS system configuration definition can be edited by selecting it in the z/OS system configuration list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the configuration list form. Alternatively a configuration definition can be edited also by clicking on the configuration name in the table of the z/OS system configuration list form. After that a form with the z/OS system configuration definition fields appears. This form has the same input fields like the form for a new configuration definition.

Creating a copy of a z/OS system configuration

An z/OS system configuration definition can be copied by selecting it in the z/OS system configuration list form (checking the check-box at the beginning of the table row) and clicking the Copy button in the configuration list form. After that the form for a new configuration, prefilled with the values of the selected configuration appears. Before saving the configuration definition at least the name of the configuration has to be changed.

Deleting z/OS system configurations

One or more z/OS system configurations can be deleted by selecting them in the z/OS system configuration list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the configuration list form.

A new account can be defined by clicking the New button in the accounts list form. After that a form with the account definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new account is created and appears in the accounts list. By clicking the Cancel button the dialog returns to the accounts list without creating a new account.

In the field Client the client in which the account shall be defined has to be selected.

The field Name has to be filled with the user name, which is used to login into ProcMan. The user name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored.

The check-box Case sensitive specifies whether the name shall be handled as case sensitive or insensitive. If it is checked the name will always to be typed exactly like in this form at login. Otherwise any alphabetic letter in the user name can be typed as a capital or a small letter at login.

In the field Description the new account can be described. If the account is related to a real person, its full name can be typed here. If it is a special account, for example an administrator or a technical user, it can be described what the account is good for here. This field can also be left empty.

In the field z/OS Login a previously defined authentication z/OS system can be selected. (How to configure authentication z/OS systems is described in later chapters). If a system is selected no password is required to be specified for the user in this dialog.

The check-box Database Login specifies whether the user name and password specified at login shall be verified by the database server. If it is checked no password is required to be specified for the user in this dialog.

The fields Password and Repeat Password have to be filled with the initial password of the user. Both must not be empty and must contain the same text.

In the field Timezone the timezone of the user can be selected. This information is being used in ProcMan to display timestamps in the proper timezone of the user. This field can also be left empty. In this case the timezone of the ProcMan server is being used for the account. Alternatively the timezones can be assigned to accounts also in the Timezone assignment administration dialog.

In the field Company the company of the user can be filled. It can also be left empty.

In the field Department the department of the user can be filled. It can also be left empty.

In the field Telephone the phone number of the user can be filled. It can also be left empty.

In the field Mobile the mobile-phone number of the user can be filled. It can also be left empty.

In the field E-mail the e-mail address of the user can be filled. It can also be left empty. If the field is filled and ProcMan is configured to sending e-mails via an SMTP server (see the documentation ProcMan – Install and Customize), generated messages will be sent to this e-mail address depending on settings done in the Processes administration dialogs.

The check-box Enabled specifies whether the account can be used in ProcMan or not. If an account is not enabled it behaves like if it would not be defined at all.

In the section Additional Recipients can be specified who else shall be notified by an email when a notification email is sent to the user. The recipients can be specified by entering email addresses and/or by entering process parameter names from which email addresses shall be read and/or by selecting roles from the list of roles (to specifiy that all users having the selected role in the current client context shall be recipients) and/or by selecting users from the list of users in this section.

One or more accounts can be deleted by selecting them in the accounts list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the accounts list form. An alternative to the delete of an account is to disable it.

A user can have different roles in different clients. The role assignment is used in ProcMan to specify which roles a user has in which clients. A user must have at least one role in one client assigned to be able to login in ProcMan.

The role assignment dialog in ProcMan can work in two modes: ‘assigning users to a role’ or ‘assigning roles to a user’. Both modes lead to the same results.

An account definition can be edited by selecting it in the accounts list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the accounts list form. Alternatively an account definition can be edited also by clicking on the account name in the table of the accounts list form. After that a form with the account definition fields appears. This form is the same like the form for a new account except, that the fields Client, Name and the Case sensitive check-box are read-only and cannot be changed and the fields Password and Repeat Password are missing.

This form can be used for editing of accounts verified by ProcMan as well as those verified by a LDAP server at login.

Timezones assignment to accounts is used in ProcMan to display timestamps in the proper timezone of the users. If no timezone is assigned to an account the ProcMan server timezone is being used.

Alternatively to the timezone assignment dialog the timezones can also be set in the account definition of every single user.

By clicking on the Timezone assignment menu item the timezone assignment administration dialog is being started (see picture below).

This dialog can be left by clicking the Cancel button. It can also be left at any time by selecting another function from the ProcMan menu.

By clicking the OK button the timezone selected in the field Timezone is assigned to the selected accounts in the Users table (the check-box at the beginning of the table row is checked).

Beware that the password changing dialog cannot be started for LDAP authenticated accounts.

Beside that the password of a user can be changed in this dialog, it allows also to switch among the ProcMan, the z/OS and the database server authentication methods.

A password can be changed for an account by selecting it in the accounts list form (checking the check-box at the beginning of the table row) and clicking the Password button in the accounts list form. After that a form for changing of the password appears (see picture below).

By clicking the Cancel button, the dialog returns to the accounts list without changing the password.

By clicking the OK button the dialog changes the password for the previously selected user and returns to the accounts list.

The read-only field Name informs about the user name of the account for which the password or authentication method shall be changed.

The check-box Database Login specifies whether the user name and password specified at login shall be verified by the database server. If it is checked, no password is required to be specified for the user in this dialog.

The fields Password and Repeat Password have to be filled with the new password of the user. Both must not be empty and must contain the same text.

By clicking on the Role assignment menu item the role assignment administration dialog is being started. After the dialog has been started, the list of roles which can be assigned to users in the current client and its descendant clients is displayed (see picture below).

The mode of the dialog can be changed by selecting Assign roles to a user in the selection field above the list. The list of roles changes into the list of users which can be assigned to roles in the current client and its descendant clients (see picture below) in this case.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the following forms for assigning users to a role or for assigning roles to a user, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

If the mode Assign roles to a user is selected and a user is selected (the radio-button at the beginning of a row in the users list table is checked), by clicking the OK button the roles assignment form is started (see picture below). Alternatively a clicking on the user name in the user’s list table has the same effect.

By clicking the Cancel button the dialog returns to the users list form discarding all changes.

In the field Client the client has to be selected in which the assignment shall be done.

In the Roles table roles has to be selected (by checking the check-box at the beginning of the rows) which shall be assigned to the previously selected user in the specified client. In the Roles table some check-boxes can be checked and read-only which means that the roles are already assigned to the user in an ancestor client of the specified client and thus this assignment is inherited and effective also in the specified client.

After the assignment in one client has been done, another client can be selected in the field Client and roles can be selected for assignment to the user and so on. The dialog remembers assignments in all selected clients which have been done.

By clicking the OK button all the assignments are saved and the dialog returns to the users list form.

If the mode Assign users to a role is selected and a role is selected (the radio-button at the beginning of a row in the roles list table is checked), by clicking the OK button the users assignment form is started (see picture below). Alternatively a clicking on the role name in the roles list table has the same effect.

By clicking the Cancel button the dialog returns to the roles list form discarding all changes.

In the field Client the client has to be selected in which the assignment shall be done.

In the Users table users has to be selected (by checking the check-box at the beginning of the rows) which shall be assigned to the previously selected role in the specified client. In the Users table some check-boxes can be checked and read-only which means that the users are already assigned to the role in an ancestor client of the specified client and thus this assignment is inherited and effective also in the specified client.

After the assignment in one client has been done, another client can be selected in the field Client and users can be selected for assignment to the role and so on. The dialog remembers assignments in all selected clients which have been done.

By clicking the OK button all the assignments are saved and the dialog returns to the roles list form.

Calendars are global objects in ProcMan, which means that they are not defined in clients or other objects.

Calendars in ProcMan are dedicated to specify free days (Saturdays, Sundays, New Year’s Day, etc.). They are used for selection and checking of process entry date, time and timestamp values, which are foreseen to contain only values referring to working days.

Calendars are in ProcMan organized hierarchically. Any calendar can be a root calendar (with no parent calendar) or a child calendar of another calendar. Any calendar can have an arbitrary count of children calendars. The hierarchy of calendars can be arbitrarily deep. If a calendar has a parent calendar it inherits free day definitions from all its ancestor calendars.

Calendars list

By clicking on the Calendars menu item the calendar administration dialog is being started.

After the dialog has been started, the list of already defined calendars is displayed (see picture below). If there are no calendars a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the calendar definition forms for new and edited calendars, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Creating a new calendar

A new calendar can be defined by clicking the New button in the calendars list form. After that a form with the calendar definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new calendar is created and appears in the calendars list. By clicking the Cancel button the dialog returns to the calendars list without creating a new calendar.

The field Name has to be filled with the name of the new calendar. The name of the calendar can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

In the field Parent the parent calendar of the new calendar has to be selected or it can be left empty.

The field Description can be filled with a textual description of the new calendar. It is a free text, which can contain any printable characters. It also can be left empty.

In the field Regular free days the days which are considered to be free days every week can be selected. By checking check-boxes in the Free day column can be specified which week days shall be handled as free days. By checking check-boxes in the Allow selection column can be specified which free days shall be handled as work days (ProcMan allows a special handling of such week days, e.g. to show a warning in the case that such day has been selected).

The Merge with parent regular free days check-box appears only in the case that the new calendar has a parent calendar specified. If the check-box is checked the fee days settings inherited from the ancestor calendars and shown in the additional columns Free day from Parent and Allow selection from Parent are used in the new calendar without a need to do them for the new calendar again. However there can be selected further days in addition to the inherited days in the field Regular free days in the new calendar. If the check-box is not checked only days selected in the field Regular free days will be used by the new calendar.

In the table Other free days you can define days which are considered as free days and associated to a special date. If the new calendar has specified a parent calendar the free days inherited from the ancestor calendars are displayed at the beginning of the table as read-only rows. The date to which the free day is associated has to be filled in the Date column. The filled value has to contain at least the day and the month, optionally also the year. If the year is required but not specified the current system year is filled in by ProcMan.

The date field accepts different date formats e.g. YYYY-MM-DD, DD.MM.YYYY or MM/DD/YYYY. For the date selection the picker (button with question mark) right of the date-edit field can be used. In the field in the column Description a description of the free day can be typed. If the check-box in the Every year column is checked it means that the entered date made of the day and the month is a free day every year. In this case the year needs not to be specified in the date field as it is ignored anyway. If the specified free day is/was an every year free day only in some period, the years when it started to be a free day and/or the year when it finished to be a free day can be specified by selecting the years in the Since year and Until year columns. The check-box in the Allow selection column specifies when checked that the date can be used as a working day even though it is a free day. The buttons New and Delete below the table can be used to create new rows in the table or delete rows selected by checking the check-box at the beginning of the table rows.

Editing a calendar

A calendar definition can be edited by selecting it in the calendars list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the calendars list form. Alternatively a calendar definition can be edited also by clicking on the calendar name in the table of the calendars list form. After that a form with the calendar definition fields appears. This form is the same like the form for a new calendar.

Deleting calendars

One or more calendars can be deleted by selecting them in the calendars list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the calendars list form. Beware that with the calendars also all descendant calendars are deleted.

Adding calendars into the Transfer Case

Select one or more calendars from the calendars list form (checking the check-button at the beginning of the table rows) and click the Into Transfer Case button in the calendars list form. After the selected calendars have been added into the Transfer Case you can add another calendars or another objects into the Transfer Case or continue with other administration work. For more information about the Transfer Case see the description of the Transfer Case tool in this document.

To achieve that processes of a client can use a calendar for selecting and checking their date, time and timestamp values for using only working days, the calendar has to be assigned to the client. A calendar can be assigned to as many clients as needed. To a client only one calendar can be assigned. If no calendar is assigned to a client there are all dates handled as working days.

Alternatively to the calendar assignment dialog a calendar can be assigned to a client also in the client definition.

Calendar assignment

By clicking on the Calendar assignment menu item the calendar assignment administration dialog is being started.

After the dialog has been started, the list of already defined calendars is displayed (see picture below). If there are no calendars defined a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the following calendar to clients assignment form, by selecting another function from the ProcMan menu. If this happens in the following form the last changes done in the form are discarded.

Calendar to clients assignment

A calendar assignment can be started by selecting it in the calendars list form (checking the radio-button at the beginning of the table row) and clicking the OK button in the calendars list form. Alternatively a calendar assignment can be started also by clicking on the calendar name in the table of the calendars list form. After that a form with the clients list appears (see picture below).

By clicking the Cancel button the dialog returns to the calendars list form discarding all changes.

In the Clients table clients can be selected (by checking the check-box at the beginning of each client row) to which the previously selected calendar shall be assigned.

By clicking the OK button the assignment is saved and the dialog returns to the calendars list form.

The search function in the work list (or any other filter list) returns processes containing a specified text in selected search areas (e.g. description, memo, JCL member name, etc.). The selection of the search areas allows the user to specify more precisely for what shall be searched and it avoids a lot of trash (uninteresting processes) returned by the search function. The classification of process data into the search areas is realized by the definition of the search areas and their association with the input fields of the process forms. Values filled in such input fields are stored (after submission of the forms) in a way, that the search function knows in which stored values it shall search for the specified text depending on the selected search areas.

There is no need to define search areas for all process data. Useful searches are for: object name, JCL account parameter etc. See also filter functions.

The association between search areas and input fields in process forms can be done for common process forms in the Global definitions and Process definitions dialogs. If the process forms are generated by proprietary php scripts the association can be done by using ProcMan API functions defined in the httpd/htdocs/hwm_api.php script in the ProcMan installation directory. The API functions are documented in the script itself, but this way to build the associations is dedicated only for advanced php developers.

The search areas in ProcMan can be organized in a hierarchy of search area groups. This allows clustering of search areas which logically belong together and provides the user with a possibility to select/deselect a whole group of search areas in the work list search function by one click. Any group can be a root group (has no parents) or a child group of another group. Any group can contain an arbitrary count of search areas and/or child groups. The search area group hierarchy can be arbitrarily deep.

Search area list

By clicking on the Search areas menu item the search area administration dialog is being started.

After the dialog has been started, the list of already defined search areas and groups is displayed (see picture below). If there are no search areas and/or groups defined a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the search area definition forms for new and edited search areas, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Actions list

By clicking on the Actions menu item the actions administration dialog is being started.

After the dialog has been started, the list of already defined actions is displayed (see picture below). If there are no actions defined a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the action definition forms for new and edited actions, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Creating a new action

A new action can be defined by clicking the New button in the actions list form. After that a form with the action definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new action is created and appears in the actions list. By clicking the Cancel button the dialog returns to the actions list without creating a new action.

In the field Client the client in which the action will be created has to be selected.

The field Name has to be filled with the name of the new action. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

The field Description can be filled with a textual description of the new action. It is a free text, which can contain any printable characters. It also can be left empty.

The field Command has to be filled with the command which shall be executed by the action. Currently only php scripts in the ProcMan installation directory on the ProcMan server can be used as executable commands.

In Command parameters parameters of the command can be specified by their names and values, if any needed.

In the field Role a role can be selected to specify that the action can only be started by users having assigned the selected role.

The check-box Enabled specifies whether the action can be used in ProcMan or not. If an action is not enabled it behaves like if it would not be defined at all.

Editing an action

An action definition can be edited by selecting it in the actions list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the actions list form. Alternatively an action definition can be edited also by clicking on the name in the table of the actions list form. After that a form with the action definition fields appears. This form is the same like the form for a new action except, that the field Client is read-only and cannot be changed.

Copying an action

An existing action can be used as a base for a new one by selecting it in the actions list form (checking the check-box at the beginning of the table row) and clicking the Copy button in the actions list form. After that the form for a new action prefilled with the settings from the selected action appears. Beware that at least the action name must be changed before the new action can be created.

Deleting actions

One or more actions can be deleted by selecting them in the actions list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the actions list form. Beware that only actions which are not in use by process definitions can be deleted. An alternative to the delete of an action is to disable it.

Adding actions into the Transfer Case

Process definitions can be seen as types of processes handled by ProcMan. Every process in ProcMan must be started as an instance of a process definition. A process definition contains settings necessary for the life cycle of processes using it, like user parameters which have to be specified when starting a process, definition of activities, dependencies among the activities, etc.

Each process definition must use a global definition. Settings stored in a global definition are shared by all process definitions using it, which means that they take effect in all processes of all process definitions using the global definition. Settings special for a kind of processes are stored in the process definition, which means that they take effect only for processes using the process definition.

Process definitions list

By clicking on the Process definitions menu item the process definitions administration dialog is being started.

After the dialog has been started, the list of already defined process definitions is displayed (see picture below). If there are no process definitions defined a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the process definition forms for new and edited process definitions, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Creating a new process definition

A new process definition can be defined by clicking the New button in the process definitions list form. After that a form with the process definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new process definition is created and appears in the process definitions list. By clicking the Cancel button the dialog returns to the process definitions list without creating a new process definition.

In the field Client the client in which the process definition will be created has to be selected.

In the field Global definition the global definition used by the process definition has to be selected.

The field Name has to be filled with the name of the new process definition. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

The field Description can be filled with a textual description of the new process definition. It is a free text, which can contain any printable characters. It also can be left empty.

In the field Role of process creator the role has to be selected, which a user must have assigned, to be able to create processes of this process definition.

In the field Role with permission to read reports a role can be selected, which allows users having this role, to access the process reports of processes of this process definition, even if they are not permitted to change anything in the processes and/or their activities.

The check-box Allow creation of new processes specifies whether new process instances of this process definition can be created. If it is unchecked, users still can proceed with they work in existing processes of this definition in the work list (submit, interrupt, reject, complete, etc. activities of the processes), but no new processes of this definition can be created.

The check-box Enabled specifies whether the process definition can be used in ProcMan or not. If a process definition is not enabled it behaves like if it would not be defined at all.

Further fields are organized in sections. Each section can be opened or closed by clicking on the plus (+) or minus (-) control element in the front of the section title.

Process definition specific process parameters

In this section process parameters can be defined for all processes using this process definition. The values of these parameters can be filled by users in the dialog for process creation, in dialogs of process activities or evaluated and set by the process activities without user interaction. In opposite to parameters defined in the global definitions parameters defined in process definitions are not displayed in the work list.

Moreover based on the parameter definitions in this section the process creation dialog is generated for processes using this process definition. The generated dialog provides users with entry fields for setting values of the process parameters. The look of these entry fields has also to be defined here.

The fields of this section can be edited when the section is open (see picture below).

The structure of this section is similar to the structure of the section Global definition specific process parameters in the Global definitions administration dialog. In this chapter only differences between these two sections are described. Please refer to the description of Global definition specific process parameters for more information.

If the check-box in the field Include process parameters from the global definition is checked (which is the default), the parameters defined in the global definition used by this process definition are used for the generation of the process creation dialog. In this case the global definition parameters are also displayed in the table of parameters in this section. If the check-box is not checked the global definition parameters are ignored when the process creation dialog is generated and they are not displayed in the table of parameters in this section.

In the rows for the general and global definition parameters in the parameters table there is a Change or a Global button at the end of each row. By clicking the Change button the button description changes to Global and the check-box in the Show in process dialog field (only for parameters defined in the global definition) and the Edit button in the Process dialog attributes field of the row become active. This allows changing the behavior and the look of the parameter fields in generated dialogs, inherited from the global definition, for processes of this process definition. By clicking a Global button the button description changes to Change and the check-box in the Show in process dialog field (only for parameters defined in the global definition) and the Edit button in the Process dialog attributes field of the row become read-only. In this case the changes (if any) done in the process definition for the parameter are ignored and the behavior and the look of the parameter fields in generated dialogs inherited from the global definition will be used.

Attachment of files

In this section can be specified whether external files (e.g. pdf, doc, ppt, etc.) can be attached to processes using this process definition.

The fields of this section can be edited when the section is open (see picture below).

If the check-box in the field Get the attachment settings from the global definition is checked it depends on the settings in the global definition whether it will be allowed to attach external files to processes using this process definition or not (for the global definition this property is set in the Attachment of files section in the Global definitions administration dialog). If the check-box is checked the check-box in the field Allow attachment of files is read-only and depending on what is set in the global definition it is checked or not. Otherwise the setting inherited from the global definition can be changed in this process definition.

If the check-box in the field Allow attachment of files is checked it will be allowed to attach external files to processes using this process definition.

Status of activities

In this section can be specified what status of activities of all processes using this process definition shall be set dependent on the returned control code of the actions executed by the activities. The control codes in ProcMan are strings. To set a control code the programs executed by an action has to call the API function hwm_set_return_code (the function is described in httpd/htdocs/hwm_api.php where it is defined).

The definitions done in this section are to be seen as defaults which can be overridden for each process activity. Defining the most common (or even all if possible) mappings of control codes to activity statuses here spares a lot of definition work by avoiding the necessity of repeating the same specifications for all activities using the process definition.

The fields of this section can be edited when the section is open (see picture below).

The structure of this section is similar to the structure of the section Status of activities in the Global definitions administration dialog. The only difference is that the settings inherited from the global definition are displayd here in read-only modus for information. Please refer to the description of Status of activities of global definitions for more information.

Sending of messages

In this section can be specified in which cases e-mail messages shall be sent to which users. Sending of messages in two situations can be defined here: when the status of a process of this process definition has been changed and when the status of an activity of a process of this process definition has been changed.

The definitions done in this section for sending messages when the status of activities has been changed are to be seen as defaults which can be overridden for each process activity. Defining the most common (or even all if possible) message sending rules here spares a lot of definition work by avoiding the necessity of repeating the same specifications for all activities using the process definition.

Beware that e-mails can be sent only if an SMTP server has been configured after the ProcMan installation (please refer to the ProcMan installation and customize guide for more information). Moreover e-mails can only be sent to users which have an e-mail address specified in their accounts.

The fields of this section can be edited when the section is open (see picture below).

The structure of this section is similar to the structure of the section Sending of messages in the Global definitions administration dialog. In this chapter only differences between these two sections are described. Please refer to the description of Sending of messages of global definitions for more information.

The tables with message sending definitions for both parts: when processes change their status and when activities change their status contain message sending definitions inherited from the global definition displayed as readonly rows.

If the check-box in the field Include message sending from the global definition is checked, the message sending definitions for messages sent when processes change their status are inherited from the global definition and displayed in the table as readonly rows. If the check-box is not checked the message definitions from the global definition are neither inherited nor displayed. Beware that the checking or not of this check-box has no effect on the definitions of messages sent when activities change their status which are always inherited from the global definition.

Process Activities

In this section the activities of the process definition, the dependencies among them and other settings relevant to process activities has to be defined. An activity is associated with exactly one action which is executed when the activity is started from the work list. The ProcMan controls whether an activity can be started depending on fulfillment of its preconditions. Moreover ProcMan manages who is authorized to start an activity dependent on the role associated with it.

The fields of this section can be edited when the section is open (see picture below).

The activitiy definitions are displayed as a table where each row represents one activity. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity. The name can be eight characters long and can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase. The activity id must be unique in the scope of one process definition but the same ids can be used in different process definitions.

If the check-box in the field OR Precondition is checked this activity becomes active (status Ready) if at least in one of the dependencies between the predecessor activities and this activity the dependency condition is fulfilled. If the check-box is not checked in all the dependencies between the predecessor activities and this activity the dependency conditions must be fulfilled before this activity becomes active.

If the check-box in the field Start Activity is checked the activity of a process becomes the status Ready and can be started immediately after the process has been created.

If the check-box in the field End Activity is checked the activity will be an end activity. A process becomes the status Complete only if all the end activities of the process have the status Complete.

In the field Role the role which is authorized to start this activity can be selected. If a role is selected here then this role is authorized to start the activity. If it is empty the role specified in the action definition of the action selected in the Action Id field is authorized to start the activity.

In the field Action Id the action has to be selected which shall be executed by the activity. It can be selected from a list of defined actions which appears when clicking the question mark (?) button right of the field.

In the field Report Action Id the action has to be selected which shall be executed when the report function of the work list is called for the activity. It can be selected from a list of defined actions which appears when clicking the question mark (?) button right of the field.

If the check-box in the field Include status setting from the global definition is checked the settings done in the Status of activities section of the global definition are used for this activity. Otherwise they are not used.

If the check-box in the field Include status setting from the process definition is checked the settings done in the Status of activities section of the process definition are used for this activity. Otherwise they are not used.

If the check-box in the field Include message sending from the global definition is checked the settings done in the Sending of messages section of the global definition are used for this activity. Otherwise they are not used.

If the check-box in the field Include message sending from the process definition is checked the settings done in the Sending of messages section of the process definition are used for this activity. Otherwise they are not used.

Further fields are organized in subsections. Each subsection can be opened or closed by clicking on the plus (+) or minus (-) control element in the front of the subsection title.

Autocomplete of activities

In this subsection can be specified, that some activities can be completed automatically, without calling the associated action.

The fields of this subsection can be edited when the subsection is open (see picture below).

The autocomplete entries are displayed as a table. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity which shall be autocompleted.

The field Condition has to be filled with the condition expression which is being evaluated when the status of the activity specified in the field Activity Id becomes Ready. If the condition is fulfilled (the result of the evaluated expression is handled as a logical true), the activity is being autocompleted, otherwise it is handled as a manual activity and must be started from the work list by a user with the appropriate role. The syntax of the expression in this field is the same like of the conditions in process parameter definitions (see Global definition specific process parameters).

The field Control Code has to be filled with the control code which shall be set when the condition is fulfilled and the activity is being autocompleted. In this case the status of the activity is set depending on the Status of activities settings set in the global definition, process definition and/or activities of the process definition.

In the case on the screenshot above the activity TEST is being autocompleted, if the value of the process parameter TICKET.AC is '1', otherwise it is a manual activity. The value of the process parameter can be set in the process creation dialog and/or in the activity DEV.

There can be specified more entries for one activity in this section. In this case the first entry for which the condition is fulfilled is used for setting the control code and status of the activity when the autocomplete expressions are evaluated.

Autoexecute of activities

In this subsection can be specified, that the actions of some activities can be executed automatically, without a need to manually submitting them from the work list.

The fields of this subsection can be edited when the subsection is open (see picture below).

The autoexecute entries are displayed as a table. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity which shall be autoexecuted.

The field Condition has to be filled with the condition expression which is being evaluated when the status of the activity specified in the field Activity Id becomes Ready or Interrupted or Recalled. If the condition is fulfilled (the result of the evaluated expression is handled as a logical true), the activity is being autoexecuted, otherwise it is waiting for the fulfillment of the condition, without changing its status. The syntax of the expression in this field is the same like of the conditions in process parameter definitions (see Global definition specific process parameters).

Activities defined in this way can however be submitted also manually from the work list. A special dialog appears in this case. It allows a manual emergency execution or rejection of the automatic action.

Beware, that the actions of such activities can only be autoexecuted, when the Automaton background process (service) is running and properly configured for the autoexecution.

Beware, that not any defined action can be specified in process activities for autoexecutions. The command called by the action must be implemented and configured in a way, so that it supports the autoexecution.

Status of activities

In this subsection can be specified what status of activities of all processes using this process definition shall be set dependent on the returned control code of the actions executed by the activities. The control codes in ProcMan are strings. To set a control code the programs executed by an action has to call the API function hwm_set_return_code (the function is described in httpd/htdocs/hwm_api.php where it is defined).

If there has been specified for an activity that the status settings from the global and/or process definition are to be included, the settings done in the Status of activities section of the global and/or process definition will be used for the activity without a need to do the same settings here again. Only in the case that the action called by the activity can return also control codes not specified in the global and/or process definition or if a different activity status shall be set for a control code than specified in the global and/or process definition a new specification must be done here. If no status settings are included from the global and/or process definition for an activity, mapping of all possible control codes returned by the action called by the activity to the activity statuses has to be done here.

The fields of this subsection can be edited when the subsection is open (see picture below).

The structure of this subsection is similar to the structure of the section Status of activities in the Global definitions administration dialog. The only difference is the additional field Activity Id at the beginning of each table row where the name of the activity has to be specified for which the other settings in the row shall take effect. Please refer to the description of Status of activities of global definitions for more information.

Dependencies

In this subsection dependencies for defined activities can be created. A dependency is a relation between two activities where one of them is a predecessor and the other is a successor. There is a condition assigned to each dependency. After the action started by the predecessor activity ends, the control code returned by the action is checked against the condition of the dependency. If the control code matches the condition, the dependency is fulfilled. If all dependencies (for OR preconditions at least one of the dependencies) between predecessor activities and a successor activity are fulfilled, the precondition of the successor activity is fulfilled and the successor activity becomes active (status Ready).

There can also be defined special GOTO dependencies among activities in ProcMan. Such dependencies are ignored in the precondition check of successor activities. If a GOTO dependency is defined between a predecessor and a successor activity and the action started by the predecessor activity returned a control code matching the condition of the dependency, no precondition check takes place for the successor activity and the successor activity becomes active (status Ready).

The fields of this subsection can be edited when the subsection is open (see picture below).

The dependencies are displayed as a table where each row represents one dependency. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity which shall be the predecessor of the dependency.

The field Successor Activity Id has to be filled with the name of the activity which shall be the successor of the dependency.

If the check-box in the field GOTO (no precondition check) is checked the dependency is set to be a GOTO dependency (described above).

In the field Condition the operator has to be selected which shall be applied to compare the control code returned by an action started by the predecessor activity with the parameters of the condition.

In the fields Condition Parameter 1 and Condition Parameter 2 the parameters of the condition operator has to be specified. Two parameters are used only for operators testing whether the control code returned by an action is within or without a range. By other operators the second parameter is ignored. By the operators Anyway and Otherwise also the first parameter is ignored. If the operator Anyway is set, any control code matches the dependency condition and the dependency becomes always fulfilled. If the operator Otherwise is set, no control code matches the dependency condition and the dependency never becomes fulfilled, which makes sense in some cases when for the successor activity the OR precondition is set. Beware that the parameters are handled as integers only if the value of the control code as well as the values of the parameters contain only digits. Otherwise they are handled as strings.

Sending of messages

In this section can be specified to which users e-mail messages shall be sent when the status of the activities has been changed.

If there has been specified for an activity that the message sending from the global and/or process definition are to be included, the settings done in the Sending of messages section of the global and/or process definition will be used for the activity without a need to do the same settings here again. Only in the case that the messages in situations not specified in the global and/or process definition or if massages shall be send to different users than specified in the global and/or process definition, a new specification must be done here. If no message sending specifications are included from the global and/or process definition all the message sending definitions for the activity have to be done here.

The fields of this subsection can be edited when the subsection is open (see picture below).

In the part Messages sent to users when processes change their status activities can be specified, to the last update users of which shall a message be sent, when the process changes its status. When status has to be set to the status on which the message shall be sent. Activity Id (Message last update User of activities) has to be set to the activity name of the activity of which the last update user shall be notified.

The structure of the first table of the part Messages sent to users when process activitys change their status is similar to the structure of the section Sending of messages in the Global definitions administration dialog. The only difference is the additional field Activity Id at the beginning of each table row where the name of the activity has to be specified for which the other settings in the row shall take effect. Please refer to the description of Sending of messages of global definitions for more information.

In the second table of the part Messages sent to users when process activities change their status activities cab be specified, to the last update users of which shall a message be sent, when process activities change their status. Activity Id has to be set to the activity name of activity, of which status change shall cause the sending of a message. When status has to be set to the status on which the message shall be sent. Activity Id (Message last update User of activities) has to be set to the activity name of the activity of which the last update user shall be notified.

Activity Recall Conditions

In this subsection can be specified from which status an activity can be recalled, eventually dependent on the status of successor activities and who can recall the activity.

The fields of this subsection can be edited when the subsection is open (see picture below).

The recall conditions are displayed as a table where each row represents one recall condition. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity for which the recall condition in the row is specified.

In the field When Status the satus has to be selected from which the activity can be recalled.

The field Successor Activitiy Id can be filled with the name of the successor activity. If no successor is specified the recall of the activity from the specified status can be done independent on the status of successors.

The field When Successor Status the status of the successor specified in Successor Activity Id can be selected. If the successor activity and its status are specified, the activity can be recalled from the specified status only if the successor has the specified successor status. There can be more rows in the table which differ only in the status of the successor status. In this case the recall of the activity is possible if the recall condition in one of the rows is fulfilled. If the activty has more successors, conditions for all the acceptable statuses of all successors for the recall of the activity has to be defined here. In this case for each successor is checked whether there is a corresponding condition specified here to allow the recall of the activity.

If the check-box in the field Admin is authorized is checked the administrator is allowed to recall the activity if the condition specified in this row is fulfilled.

If the check-box in the field Process Creator is authorized is checked the creator of the process is allowed to recall the activity if the condition specified in this row is fulfilled.

If the check-box in the field Last Update User of the Activity is authorized is checked the last user which started the activity is allowed to recall the activity if the condition specified in this row is fulfilled.

If the check-box in the field Other users are authorized is checked any user which has the role authorized to start the activity is allowed to recall the activity if the condition specified in this row is fulfilled.

Process delete conditions

In this subsection can be specified for all activities which status they can have to be allowed to delete the process. When a process is deleted, there is checked whether for all activities of the process a delete condition is fulfilled. It is enough that for one activity no delete condition is fulfilled to refuse the deletion of the process.

The fields of this subsection can be edited when the subsection is open (see picture below).

The process delete conditions are displayed as a table where each row represents one delete condition. Rows in the table can be added or deleted by clicking plus (+) or minus (-) buttons at the end of each row.

The field Activity Id has to be filled with the name of the activity for which the process delete condition in the row is specified.

In the field When Status the satus has to be selected in which the activity can be to allow the deletion of the process.

If the check-box in the field Admin is authorized is checked the administrator is allowed to delete the process if the condition specified in this row is fulfilled.

If the check-box in the field Process Creator is authorized is checked the creator of the process is allowed to delete the process if the condition specified in this row is fulfilled.

If the check-box in the field Last Update User of the Activity is authorized is checked the last user which started the activity is allowed to delete the process if the condition specified in this row is fulfilled.

If the check-box in the field Other users are authorized is checked any user which has the role authorized to start the activity is allowed to delete the process if the condition specified in this row is fulfilled.

The field How many Days after the last update date can be specified how many days after the last change in this activity has been done and the condition specified in this row is fulfilled the process can be deleted. Here a positive integer value must be filled in.

Process cleanup action

In this section a cleanup action can be selected, which is called when a process of this process definition is being deleted. The cleanup action can for example remove all entries in the database associated with the deleted process, delete all temporary files used by the process, etc. If there is no cleanup action selected, no action is being called when a process of this process definition is being deleted.

The fields of this subsection can be edited when the subsection is open (see picture below).

In the field Cleanup Action the action which shall be called when a process of this process definition is being deleted can be selected. The selection can be done from a list of defined actions which is displayed by clicking the question mark (?) button right to the field for displaying the name of the selected action. By clicking the Clear button the selection is cleard.

Documentation

When a user is creating a process of this process definition, editing it, working in an activity of it or viewing the report for it he can open the process documentation by clicking the documentation icon in the top of the ProcMan window (see picture below). In this case the process documentation is generated from the entries done in the documentation section of the global definition and from the entries done in this section.

The process documentation is organized in chapters which can contain a multiline plain text, but no objects like pictures, tables, etc.

The fields of this section can be edited when the section is open (see picture below).

The structure of this section is similar to the structure of the section Documentation in the Global definitions administration dialog. The only difference is that the documentation inherited from the global definition is displayed here in read-only modus for information. Please refer to the description of Documentation of global definitions for more information.

Editing a process definition

A process definition can be edited by selecting it in the process definitions list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the process definitions list form. Alternatively a process definition can be edited also by clicking on the name in the table of the process definitions list form. After that a form with the process definition fields appears. This form is the same like the form for a new process definition except, that the fields Client and Global Definition are read-only and cannot be changed.

If there are already processes using the edited process definition in ProcMan, the activities and/or activity dependencies has been changed and the changes has been submitted, the original process definition is renamed (the new name is set to be the original name with the current timestamp suffix) and disabled and the changed definition is saved as a new process definition. This is because the existing processes are using the activity specification of the original process definition and would not work with the activity specification changed by editing the process definition.

Copying a process definition

An existing process definition can be used as a base for a new one by selecting it in the process definitions list form (checking the check-box at the beginning of the table row) and clicking the Copy button in the process definitions list form. After that the form for a new process definition prefilled with the settings from the selected process definition appears. Beware that at least the process definition name must be changed before the new process definition can be created.

Deleting process definitions

One or more process definitions can be deleted by selecting them in the process definitions list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the process definitions list form. Beware that only process definitions which are not in use by existing processes can be deleted. An alternative to the deleting of a process definition is to disable it.

Adding process definitions into the Transfer Case

Select one or more process definitions from the process definitions list form (checking the check-button at the beginning of the table rows) and click the Into Transfer Case button in the process definitions list form. After the selected process definitions have been added into the Transfer Case you can add another process definitions or another objects into the Transfer Case or continue with other administration work. For more information about the Transfer Case see the description of the Transfer Case tool in this document.

The Object Browser provides a read-only access on the objects (e.g. Universal objects, JCL members, TWS applications, etc.) stored by ProcMan processes in the ProcMan archive. It allows a user to get information about objects, without a need to know by which processes the objects have been created/changed.

Object Browser definitions list

By clicking on the Object Browser menu item the process definitions administration dialog is being started.

After the dialog has been started, the list of already defined object browser definitions is displayed (see picture below). If there are no object browser definitions defined a message informing about this fact is displayed instead.

This dialog can be left by clicking the Cancel button. It can also be left at any time, even in the object browser definition forms for new and edited process definitions, by selecting another function from the ProcMan menu. If this happens in the forms the last changes done in the forms are discarded.

Creating a new object browser definitions

A new object browser definition can be defined by clicking the New button in the object browser definitions list form. After that a form with the object browser definition fields appears (see picture below).

After filling the fields in this form and clicking the OK button the new object browser definition is created and appears in the object browser definitions list. By clicking the Cancel button the dialog returns to the object browser definitions list without creating a new object browser definition.

In the field Client the client in which the object browser definition will be created has to be selected.

The field Name has to be filled with the name of the new object browser definition. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

The field Description has to be filled with a textual description of the new process definition. It is a free text, which can contain any printable characters. This text will be displayed in the Object Browser menu of the logged in users.

The check-box Translate description specifies whether the text specified in the Description field contains a dictionary key and has to be translated using the dictionary into the language of the logged in user.

In the field Action the action has to be selected which shall be executed when a user clicks on the menu item for this object browser definition. It can be selected from a list of defined actions which appears when clicking the question mark (?) button right of the field.

The check-box Enabled specifies whether the object browser definition can be used in ProcMan or not. If a object browser definition is not enabled it behaves like if it would not be defined at all.

In the table Roles by which the Object Browser is allowed to be started the roles can be selected, by checking the check-box in the beginning of each row. Only users having at least one of the selected roles in the client (or its sub-clients), in which they are logged in, will see this object browser definition in their menu and can start it.

Editing an object browser definition

An object browser definition can be edited by selecting it in the object browser definitions list form (checking the check-box at the beginning of the table row) and clicking the Edit button in the object browser definitions list form. Alternatively, an object browser definition can be edited also by clicking on the name in the table of the object browser definitions list form. After that a form with the object browser definition fields appears. This form is the same like the form for a new object browser definition except, that the field Client is read-only and cannot be changed.

Copying an object browser definition

An existing object browser definition can be used as a base for a new one by selecting it in the object browser definitions list form (checking the check-box at the beginning of the table row) and clicking the Copy button in the object browser definitions list form. After that the form for a new object browser defintion prefilled with the settings from the selected object browser definition appears. Beware that at least the name must be changed before the new object browser definition can be created.

Deleting object browser definitions

One or more object browser definitions can be deleted by selecting them in the object browser definitions list form (checking the check-box at the beginning of the table rows) and clicking the Delete button in the object browser definitions list form.

Adding object browser definitions into the Transfer Case

When a process is deleted from the work list the cleanup action is called, if any set in the process definition of the deleted process and the process is marked as deleted. That means that the non-admin users cannot see the deleted processes anymore but they still remain in the system inclusive standard process data like process parameters, history, memos, etc.

An administrator can use the Deleted Processes administration dialog for managing the deleted processes. To have an overview about the deleted processes can be useful for example for revision purposes. The dialog can be started by clicking the Deleted Processes menu item.

After the dialog has been started, the list of deleted processes is displayed (see picture below). If there are no deleted processes a message informing about this fact is displayed instead.

The list of deleted processes is in fact a special work list view limited to the deleted processes and with a reduced set of functions. Like in the standard work list a filter and/or the search function can be applied on the list of deleted processes.

The dialog can be left by clicking the Cancel button. Alternatively the dialog can also be left by clicking another menu item but beware, that the list of deleted processes remains set as a current work list view in the background in this case, so when the next time the work list shall be displayed, the list of deleted processes is shown again. Also if a filter is selected from the menu it is applied on the list of deleted processes in this case. The only ways, to switch off the list of deleted processes from to be the current work list view, are the Cancel button in the list or clicking the Work list menu item.

By selecting one or more process rows in the list of deleted processes by checking the check-box at the beginning of the process row and clicking the Delete button the selected processes can be completely deleted from the system.

By selecting a process row in the list of deleted processes by checking the check-box at the beginning of the process row and clicking the View button the information about the deleted process is displayed. Alternatively the clicking on the process id in the list has the same effect.

Creating a new Automaton schedule entry

A new Automaton schedule entry can be created by clicking the New button. After that a Form is displayed allowing making the schedule definition.

In the selection box Type the type of the scheduled command can be selected. Depending on the selected type additional options are displayed in the form. Currently supported command types are described later in this chapter.

The field Name has to be filled with the name of the new schedule. The name can contain simple alphanumerical characters (ä, š, ô, etc. are not allowed), underscores, dots and spaces. Spaces at the beginning and the end are ignored. After submitting the form the name is converted into uppercase.

The field Description can be filled with a textual description of the new schedule. It is a free text, which can contain any printable characters. It also can be left empty.

The field Communication id (Universal Interface configuration) has to be filled with an id of a well specified configuration of the HWM Universal Interface in the file etc/hwm_universal_interface_config.php. This setting is essential for the possibility to execute the scheduled command by the Automaton.

The field Interval (seconds) has to be filled by the interval in which the scheduled command will be periodically executed by the Automaton.

The check-box Enabled specifies whether the schedule is considered by the Automaton or not. If a schedule is not enabled it behaves like if it would not be defined at all.

The dialog can be left by clicking the Cancel button or by clicking another menu item.

The definition can be saved by clicking the Save button.

Currently supported types of scheduled commands (selection box Type):

Type Autoexec activities

The check box Search for activities with fulfilled autoexec condition in all processes and execute them has to be checked when the scheduled command shall trigger all autoexecuted activities in the work list which have fulfilled preconditions (proper status and fulfilled autoexecution condition) for an execution.

In the fields Execute only activities with action name 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 matching at least one of the specified patterns. Additional pattern fields can be added by the plus (+) buttons and removed by the minus (-) buttons at the end of the table row. The pattern strings can contain wildcards: asterisk (*) and question mark (?). Asterisk means any string even an empty. Question mark means any character.

In the fields 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. Additional pattern fields can be added by the plus (+) buttons and removed by the minus (-) buttons at the end of the table row. The pattern strings can contain wildcards: asterisk (*) and question mark (?). Asterisk means any string even an empty. Question mark means any character.

If the check box Execute activities regardless if their autoexec condition is fulfilled or not is checked, 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 check box 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.

In the fields 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. Additional fields can be added by the plus (+) buttons and removed by the minus (-) buttons at the end of the table row.

In the fields 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. Additional fields can be added by the plus (+) buttons and removed by the minus (-) buttons at the end of the table row.

In the fields 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. Additional fields can be added by the plus (+) buttons and removed by the minus (-) buttons at the end of the table row.

In the fields Exclude the specified activities from execution one or several activity ids (numbers) can be specified to avoid the triggering of the specified autoexecuted activities. Additional fields can be added by the plus (+) buttons and removed by the minus (-) buttons at the end of the table row.

Type File Sweeper

This type allows defining scheduled commands for cleaning up old files (e.g. old logs).

In the fields File specification one or several file paths have to be specified. Additional file specifications can be added by the plus (+) buttons and removed by the minus (-) buttons at the end of the table row. The file path strings can contain wildcards: asterisk (*) and question mark (?). Asterisk means any string even an empty. Question mark means any character. When the File Sweeper is running, it looks for files to be deleted, only in the file paths specified here.

In the field Time specification a relative time has to be specified. This information means for the File Sweeper, that only files older than the specified time shall be deleted. The time can be specified here using the key words like yesterday/today/tomorrow. Further entries consisting of an integer number and key words second(s)/minute(s)/hour(s)/day(s)/week(s)/month(s)/year(s) are allowed. So for example the specification -1 week means delete all files older than one week. Entries of this type can be sequenced. For example the specification -3 months -2 days means delete all files older than 3 months and 2 days. Beware that any specification pointing a time in the future will delete all files, found based on the File specification.

Editing an Automation schedule entry

An Automaton schedule entry can be edited by selecting it in the table of schedule entries in the main Automaton dialog (checking the check-box at the beginning of the table row) and clicking the Edit button in the main Automaton dialog. Alternatively a global definition can be edited also by clicking on the name in the table of schedule entries in the main Automaton dialog. After that a form for editing the selected schedule appears. This form is the same like the form for a new schedule entry except, that the field Type is read-only and cannot be changed.

Copying an Automation schedule entry

An existing Automaton schedule entry can be used as a base for a new one by selecting it in the table of schedule entries in the main Automaton dialog (checking the check-box at the beginning of the table row) and clicking the Copy button in the main Automaton dialog. After that the form for a new schedule entry prefilled with the settings from the selected schedule entry appears. Beware that at least the name of the schedule entry must be changed before the new schedule entry can be created.

Deleting Automation schedule entries

One or more schedule entries can be deleted by selecting them in the table of schedule entries in the main Automaton dialog (checking the check-box at the beginning of the table rows) and clicking the Delete button in the main Automaton dialog. An alternative to the deleting of a schedule entry is to disable it.

The transfer case tool is mainly dedicated to transfer selected object definitions, including object definitions on which the selected objects are dependent, from one ProcMan installation to another. However it can also be used for creating copies of objects in one ProcMan installation.

The dialog of the tool can be started by clicking the Transfer Case menu item. After the dialog has been started the list of objects selected for transfer from the definition dialogs of clients, roles, calendars, search areas, actions, global definitions and/or process definitions is displayed. Further a list of objects on which the selected objects are dependent is displayed as well.

The dialog can be left by clicking the Cancel button or by clicking another menu item.

The objects listed in the two lists can be exported by clicking the Export button. In this case the definitions are written in a file which can be downloaded from the ProcMan server to the local PC in the displayed file download dialog.

Objects selected by user can be removed from the Transfer Case by selecting them (checking the check-box in the beginning of the table rows) and clicking the Remove button. All objects can be removed from the Transfer Case by clicking the Clear button.

By clicking the Import button definitions previously exported from the Transfer Case of another or the same installation of ProcMan can be imported. In the displayed file upload dialog select the file containing the exported definitions and confirm the upload. The definitions from the uploaded file are listed in a displayed import dialog.

Objects which are already defined in ProcMan are marked in the table with the status Existing. Objects which have to be created have the status New. If there are some conflicts in the imported definitions, the corresponding objects have the status Conflict. In this case also a conflict description section is displayed above the table, which can be expanded or collapsed (initial status) and contains detailed description of the found conflicts. The new object definitions can only be imported if there are no conflicts. The dialog allows changing of the object names, parent objects and client assignment before the objects are created. This feature allows you also to solve eventual conflicts.

The dialog can be left by clicking the Cancel button or by clicking another menu item.

By selecting (checking the check-box in the beginning of table rows) and clicking the Remove button you can remove objects from the list. Beware that only objects on which no other objects in the list are dependent can be removed.