ECMS - Internal - IBM Workload Scheduler File Transfer Job definition

This document explains what an IBM Workload Scheduler File Transfer Job definition is.

IBM Workload Scheduler File Transfer Job definition

IBM Workload Scheduler File Transfer Job definition

The properties of an IBM Workload Scheduler File Transfer Job definition.

Select or specify properties as required.

You can specify the following information:

General

Use this page to specify general information about the job definition.

  1. Name: The name of the job definition.
  2. Workstation: The name of the workstation or workstation class on which the job runs.
  3. Description: Optionally, include a description of the job.
  4. Output conditions: Output conditions are used when you need a successor job to start only after certain conditions are satisfied by the predecessor job. They can also be used to specify alternative flows in a job stream starting from a predecessor job. The successor job is determined by which conditions the predecessor job satisfies. You can specify any number of output conditions. Output conditions can include conditions based on the successful outcome of the predecessor job, or other conditions that when met determine which flow in the job stream is undertaken.
    1. Successful output conditions: A condition that when satisfied signifies that the predecessor job completed successfully. The job status is set to SUCC. Successful output conditions can be expressed as return codes, job status, output variables or based on job log content.
      1. Condition Name: Specify a name that identifies the successful condition that must be met by the predecessor job before a successor job can run.
      2. Condition Value: Specify the value of the condition that signifies a successful outcome for the predecessor job.
      3. For example, a successful output condition might be: Condition Name STATUS_OK and Condition Value RC=0
    2. Other conditions: A condition that when satisfied by the predecessor determines which successor job runs. Conditions can be expressed as return codes, job status, output variables or based on job log content.
      1. Condition Name: Specify a name that identifies the condition that must be met by the predecessor job before a successor job can run.
      2. Condition Value: Specify the value of the condition that must be met by the predecessor job before a successor job can run.
    3. For example, you might want to create a condition that signifies that the predecessor job has completed with errors. You can define your output condition as follows: Condition Name STATUS_ERR1 and Condition Value RC=2
    4. The format of Condition Value for both successful output conditions and other conditions is as follows: (RC <operator> <operand>) where:
      1. RC: The instruction keyword
        1. Operator: The comparison operator. Allowed operators are comparison operators (=, != or <>, >, >=, <, <=) that can be combined with logical operators (AND, OR, NOT).
        2. Operand: Any integer between -2147483647 and 2147483647.
        3. Successful output conditions::
          • (RC<=3) to qualify a job as successful when the job ends with a return code less than or equal to 3.
          • NOT ((RC=0) AND (RC=1)) to qualify a job successful when the job ends with a return code different from 0 and 1.
          • (RC=2) OR (RC=4) to qualify a job successful when the job ends with a return code equal to 2 or equal to 4.
          • (RC<7) AND (RC!= 5) to qualify a job successful when the job ends with a return code less than 7 and not equal to 5.
        4. Other conditions:
          • (RC=1) for a condition named STATUS_ERR.
          • (RC=4 OR RC=9) for a condition named FIRST_PATH
          • (RC <>5) OR (RC > 2) for a condition named SECOND_FLOW
        5. In the Condition Value field for both successful conditions and other ouput conditions, you can also express the output condition using variables other than the return code. For example, you can specify three different output conditions as follows:
          • Condition Name: STATUS_ERR Condition Value: RC=0
          • Condition Name: STATUS_ERR1 Condition Value: RC=${varname}
          • Condition Name: STATUS_ERR2 Condition Value: RC=${LOG.CONTENT}
          • You can set a success or other output condition for the job by analyzing the job output. To analyze the job output, you must check the this.stdlist variable.
          • For example, you enter the following expression:
            contains("error",${this.stdlist})
            if you want to qualify a job as unsuccessful when the word "error" is contained in the job output.
          1. For a file transfer job specifically, you can set a success or unsuccess condition for the job by analyzing the job properties. For example, you enter the following expression: ${this.File.1.Size}>0
            if you want to qualify a file transfer job as successful when the size of the transferred file is greater than zero. 1. For a file transfer job specifically, you can set a success or unsuccess condition for the job by analyzing the job properties or the job output of another job in the same job stream. For example, you enter the following expression:
            ${this.NumberOfTransferredFiles}=${job.DOWNLOAD.NumberOfTransferredFiles} if you want to qualify a file transfer job as successful when the number of uploaded files in the job is the same as the number of downloaded files in another job, named DOWNLOAD, in the same job stream.
          2. All Xpath (XML Path Language) functions and expressions are supported, for the above conditions, in the Condition Value field:
            • String comparisons (contains, starts-with, matches, and so on)
            • String manipulations (concat, substring, uppercase, and so on)
            • Functions on numeric values (abs, floor, round, and so on)
            • Operators on numeric values (add, sum, div, and so on)
            • Boolean operators

Affinity

Use this page to define the affinity relationship between two or more jobs. Affinity relationships cause jobs to run on the same workstation as the affine job.

  1. IBM Workload Scheduler: Use this section to specify that a IBM Workload Scheduler job is affine to another IBM Workload Scheduler job belonging to the same job stream.
  2. Job name: The name of the instance of the IBM Workload Scheduler job with which you want to establish an affinity relationship.
  3. Recovery options: Use this page to specify the recovery options to be followed if the job abends. You can choose to stop or continue the scheduling activity, rerun the job, to display a prompt or run a recovery job. Select an option form the Action menu to specify the action to be taken when the job abends. You can also choose to issue a recovery prompt or run a recovery job, after the action selected in this menu has been performed.
  4. Stop: If the job ends in error and there is a follows dependency, processing does not continue with the next job. This is the default option. In the Prompt text field, specify a recovery prompt to be displayed if the job ends in error. The recovery prompt is an ad hoc prompt that is always displayed and its status is Not Asked. If the job ends in error, the prompt status changes from Not Asked to Asked. If the job ends successfully, the status remains Not Asked. You can add a variable to this field by clicking Add variable... and selecting an item from the list.
  5. Continue: If the job ends in error and there is a follows dependency, processing continues with the next job. The job is not listed as abended in the properties of the job stream. If no other problems occur, the job stream completes successfully.
  6. Continue after prompt: Continue with the next job after the operator has replied to the prompt. In the Prompt text field, specify a recovery prompt to be displayed if the job ends in error. The recovery prompt is an ad hoc prompt that is always displayed and its status is Not Asked: If the job ends in error, the prompt status changes fromNot Asked. to Asked. If the job ends successfully, the status remains Not Asked. You can add a variable to this field by clicking Add variable... and selecting an item from the list.
  7. Rerun: If the job ends in error, rerun the job.
    1. Retry after (hh:mm): How often IBM Workload Scheduler attempts to rerun the failed job. The default value is 0. The maximum supported value is 99 hours and 59 minutes.
    2. Number of attempts: Maximum number of rerun attempts to be performed. The default value is 1. The maximum supported value is 10.000 attempts.
    3. Run on the same workstation: Specify whether the job must be rerun on the same workstation as the parent job. This option is applicable only to pool and dynamic pool workstations.
  8. Rerun after prompt: Rerun the job after the operator has replied to the prompt. In the Prompt text field, specify a recovery prompt to be displayed if the job ends in error. The recovery prompt is an ad hoc prompt that is always displayed and its status is Not Asked . If the job ends in error, the prompt status changes from Not Asked: to Asked. If the job ends successfully, the status remains Not Asked. You can add a variable to this field by clicking Add variable... and selecting an item from the list.
    1. Run on the same workstation: Specify whether the job must be rerun on the same workstation as the parent job. This option is applicable only to pool and dynamic pool workstations.
  9. You can also choose whether you want to run a recovery job in case the parent job ends in error. Specify the following options:
  10. Job: The name of a recovery job to run if the parent job ends in error. Recovery jobs are run only once for each instance of the parent job ended in error. You can type a job name or click the Search button and select it from the list.
  11. Workstation: The name of the workstation where the recovery job runs. The name is entered automatically when you select a recovery job.

File Transfer

Use this section to define the options for the file transfer.

  1. Transfer Type: The type of transfer operation to be performed.
    1. Supported values are as follows:
      • Download
        • Permissions (Octal Notation). Specify file permissions for the user on the local system. File permissions are expressed as octal notation.
      • Upload
        • Delete source files after transfer. Specify if source files must be deleted after transfer.
  2. Server: The host name of the server where the file transfer is to be performed. If you want to specify a port number different from the default one, use the following syntax: server_name:port_number
  3. Remote file:
    • The name of the remote file that you want to transfer. When uploading, this is the target file, when downloading, this is the source file.
    • You can use asterisks (*) or question marks (?) as wildcard characters when downloading the file.
    • If you want to maintain the same file name, specify the path in the Remote file field with two backslashes (\\) or a forward slash (/) at the end of the path.
  4. Local file:
    • The name of the local file that you want to transfer. When uploading, this is the source file, when downloading, this is the target file.
    • You can use asterisks (*) or question marks (?) as wildcard characters when uploading the file.
  5. Protocol: The protocol to be used for the file transfer. Supported values are as follows:
    • FTP: A standard network protocol used to exchange files over a TCP/IP-based network, such as the Internet. When transferring files to or from a z/OS server, the SBDataconn command is used.
    • FTPS: An extension to the File Transfer Protocol (FTP) that adds support for the Transfer Layer Security (TLS) cryptographic protocol. Specifically, the file transfer is performed using implicitly the TLS security protocol for the FTP sessions, providing a private security level for the data connection. TLS protocol version 1 is supported. The SSL session reuse configuration is not supported. If you specify this protocol only the user and password authentication is supported.
    • FTPES: An extension to the File Transfer Protocol (FTP) that adds support for the Transfer Layer Security (TLS) cryptographic protocol. Specifically, the file transfer is performed using explicitly the TLS security protocol for the FTP sessions, providing a private security level for the data connection. TLS protocol version 1 is supported. The SSL session reuse configuration is not supported. If you specify this protocol only the user and password authentication is supported.
    • WINDOWS: The Microsoft file sharing protocol. Use the samba syntax to specify the path. Share the folder containing the files you want to transfer. When transferring ASCII files, the local and remote code pages are identified automatically.
    • SSH: A network protocol that provides file access, file transfer, and file management functions over any data stream. When transferring ASCII files, the local and remote code pages are identified automatically.
    • AUTO: The protocol is selected automatically between the Windows and SSH protocols. The product tries using the Windows protocol first. If this protocol fails, the SSH protocol is used. When using SSH, the path has to be in the SSH format. In this case the Cygwin ssh server is mounted on /home/Administrator.

Remote Credentials

Use this section to define the credentials for accessing the remote workstation.

  1. User name: The user name for accessing the remote workstation.
  2. Password: The password for accessing the remote workstation. You can click on the ellipsis to display the Password type options. Select one of the following buttons:
    1. Password: Takes the password value entered in the Password field.
    2. User:
      1. On dynamic agents: It is resolved at run time with the password value defined for User Name in the IBM Workload Scheduler database using either the User definition panel or the composer user command.
      2. You can also specify the user (and the related password) of another workstation if it is defined in the database. See the description of the Variable button.
      3. Attention: User definitions lack referential integrity. This implies that, if a user definition referenced in the credentials section is changed or deleted, no warning or error message is returned until the job is run.
      4. On IBM Workload Scheduler for z/OS agents: It is resolved at run time with the password value defined for User Name in the IBM Workload Scheduler for z/OS database using the USSREC initialization statement, where the value of User Name is defined by the USRNAM parameter and the password by USRPSW.
    3. Agent User: It is resolved at run time with the password value defined for User Name locally on the dynamic agent or IBM Workload Scheduler for z/OS agent that will run the job (or on any agent of a pool or dynamic pool that may run the job) with the param command.
    4. Variable: It is resolved at run time with the value defined for the variable you enter in the field (using the ${variable_name} notation).
      1. On dynamic agents: The variable must have been defined either locally on the agent, using the param command, or in the IBM Workload Scheduler database, utilizing the User panel or the composer username command.
      2. For example:
        • A variable defined locally on the agent, enter here as:
          ${agent:file_With_Sections.password.dbPwd}
        • A variable defined in the database, enter here as:
          ${password:workstation#user}
      3. You can use this button to specify the password of the remote user of a different workstation (as long as it was defined in the database) by entering the following string in the adjacent field: ${password:workstation_name:value_of_user_name_field}
      4. On IBM Workload Scheduler for z/OS agents:
        • Use this field if you want to use the password defined for a user different from the one specified in the User Name field.
        • For example if you are defining a File Transfer job and the local and remote user names are identical (user1), you can differentiate the password by defining two USRREC initialization statement entries (for example one for user1 and one for user1remote). After doing this, in the remote user password field you specify:
          ${password:user1remote}
        • The traditional variable substitution mechanism which uses variables defined in the IBM Workload Scheduler for z/OS database variable tables is not supported in this field.
      5. Variables are resolved both when you generate a plan and when you submit a job or a job stream. While defining jobs, the variables are not resolved and cannot be used in lists or for test connections.
      6. The password is not required if a keystore file path and password are specified when using the SSH protocol.

Local Credentials

Use this section to define the credentials for accessing the local workstation.

  1. User name: The user name for accessing the local workstation.
  2. Password: The password for accessing the local workstation.You can click on the ellipsis to display the Password type options. Select one of the following buttons:
    1. Password: Takes the password value entered in the Password field.
    2. User:
      1. On dynamic agents: It is resolved at run time with the password value defined for User Name in the IBM Workload Scheduler database using either the User definition panel or the composer user command.
      2. You can also specify the user (and the related password) of another workstation if it is defined in the database. See the description of the Variable button.
      3. Attention: User definitions lack referential integrity. This implies that, if a user definition referenced in the credentials section is changed or deleted, no warning or error message is returned until the job is run.
      4. On IBM Workload Scheduler for z/OS agents: It is resolved at run time with the password value defined for User Name in the IBM Workload Scheduler for z/OS database using the USSREC initialization statement, where the value of User Name is defined by the USRNAM parameter and the password by USRPSW.
    3. Agent User: It is resolved at run time with the password value defined for User Name locally on the dynamic agent or IBM Workload Scheduler for z/OS agent that will run the job (or on any agent of a pool or dynamic pool that may run the job) with the param command.
    4. Variable: It is resolved at run time with the value defined for the variable you enter in the field (using the ${variable_name} notation).
      1. On dynamic agents: The variable must have been defined either locally on the agent, using the param command, or in the IBM Workload Scheduler database, utilizing the User panel or the composer username command. For example:
        • A variable defined locally on the agent, enter here as:
          ${agent:file_With_Sections.password.dbPwd}
        • A variable defined in the database, enter here as:
          ${password:workstation#user}
        • You can use this button to specify the password of the remote user of a different workstation (as long as it was defined in the database) by entering the following string in the adjacent field:
          ${password: workstation_name # value_of_user_name_field }
      2. On IBM Workload Scheduler for z/OS agents:
        • Use this field if you want to use the password defined for a user different from the one specified in the User Name field.
        • For example if you are defining a File Transfer job and the local and remote user names are identical (user1), you can differentiate the password by defining two USRREC initialization statement entries (for example one for user1 and one for user1remote). After doing this, in the remote user password field you specify:
          ${password:user1remote}
        • The traditional variable substitution mechanism which uses variables defined in the IBM Workload Scheduler for z/OS database variable tables is not supported in this field.
        • Variables are resolved both when you generate a plan and when you submit a job or a job stream. While defining jobs, the variables are not resolved and cannot be used in lists or for test connections.
    5. Certificates: Use this section to specify a keystore file containing the private key and the keystore password used to make the connection.
      1. KeyStore file path: The fully qualified path of the keystore file containing the private key used to make the connection. A keystore is a database of keys. Private keys in a keystore have a certificate chain associated with them, which authenticates the corresponding public key on the remote server. A keystore also contains certificates from trusted entities. Applicable to SSH protocol only.
      2. Password: The password that protects the private key and is required to make the connection. This attribute is required only if you specify a keystore file path. If the keystore file path and keystore password combination fail to make a connection, then an attempt is made using the user name and password that correspond to the user authorized to start a connection on the remote computer.
    6. Test Connection: Verifies the connection to the specified

Transfer Options

Use this section to define the options for the file transfer.

  1. Transfer mode: The type of encoding for the file transfer. The following values are supported:
    • Binary
    • Text
  2. Convert code page: Select to enable code page conversion.
  3. Code page Conversion: Use this section to specify the code page used on the remote and local workstations. Ensure that the file is written in the correct code page for the destination system before transferring it.
    1. Remote code page: The code page used on the remote workstation.
    2. Local code page: The code page used on the local workstation.
    3. Timeout: Specifies the maximum number of seconds that can be used for the file transfer operation. The default value is 60 seconds.
  4. Connection Mode: The type of connection for the file transfer. Specifies whether the server is passive or active when establishing connections for data transfers. The following values are supported:
    1. Active Mode: The server establishes the data connection with the client. This is the default value.
    2. Passive Mode: The client establishes the data connection with the server.
    3. Port range: The port range to use on the client side of TCP/IP data connections. The port range limits the port numbers sent by the FTP PORT command. Use this option if you have highly restrictive firewall rules. If you do not specify port range, the operating system determines the port numbers to use. The following values are supported:
      1. Min port: The minimum port value to use on the client side of TCP/IP data connections. Specify a value in the range from 0 to 65535. For example, if you set this value to 1035, the product restricts the port numbers to be equal to or greater than port 1035.
      2. Max port: The maximum port value to use on the client side of TCP/IP data connections. Specify a value in the range from 0 to 65535. For example, if you set this value to 1038, the product restricts the port number to be less than or equal to port 1038.

Versions

Use this section to view the history of object changes and work with the different versions. You can run the following actions:

  1. Compare: Select two different versions and compare them.
  2. Restore...: Select a previous version and start the restore

Note

Credential management is different between version 8.6 and version 851, fix pack 1 because version 8.5.1, Fix Pack 1 supports only one set of credentials. A compatibility issue might arise if you use a file transfer job defined for IBM® Workload Scheduler, version 8.5.1, Fix Pack 1, or if you use a file transfer job, version 8.6, but specify a single set of credentials. If the file transfer job contains a single set of credentials, the system automatically uses the path management implemented for file transfer jobs in IBM Workload Scheduler, version 8.5.1, Fix Pack 1, where the following rule applies: - The specified path applies to the home directory of the user on the FTP, SSH, or Windows server, even in the case the path starts with a forward slash (/).




Keywords:Imaging Imaging System Experience ImageNow perceptive content ecm ecms enterprise content management imaging imagenow perceptive IBM Workload Scheduler File Transfer Job definition   Doc ID:98162
Owner:CRAIG S.Group:ECMS
Created:2020-02-21 11:59 CDTUpdated:2020-04-29 13:49 CDT
Sites:ECMS
Feedback:  0   0