Script:
Owner:
Subdir: middlewarenews
Blog ID: 93013848
Group ID: User ID: 92249378

My Profile

  • Valerie
    Valerie

  • Ravindra
    Ravindra

  • Suneel
    Suneel

  • sudheer
    sudheer

    IBM Websphere MQ (String Lengths) - Middleware News

    Tuesday, June 19, 2012, 12:44 PM
    Categories: WebSphere MQ
    Posted By: Karthick

    MQ (String Lengths)

    MQ_ABEND_CODE_LENGTH 4 X'00000004'
    MQ_ACCOUNTING_TOKEN_LENGTH 32 X'00000020'
    MQ_APPL_IDENTITY_DATA_LENGTH 32 X'00000020'
    MQ_APPL_NAME_LENGTH 28 X'0000001C'
    MQ_APPL_ORIGIN_DATA_LENGTH 4 X'00000004'
    MQ_APPL_TAG_LENGTH 28 X'0000001C'
    MQ_ARM_SUFFIX_LENGTH 2 X'00000002'
    MQ_ATTENTION_ID_LENGTH 4 X'00000004'
    MQ_AUTH_INFO_CONN_NAME_LENGTH 264 X'00000108'
    MQ_AUTH_INFO_DESC_LENGTH 64 X'00000040'
    Start of changeMQ_AUTH_INFO_NAME_LENGTHEnd of change Start of change48End of change Start of changeX'00000030'End of change
    MQ_AUTH_INFO_OCSP_URL_LENGTH 256 X'00000100'
    MQ_AUTHENTICATOR_LENGTH 8 X'00000008'
    MQ_AUTO_REORG_CATALOG_LENGTH 44 X'0000002C'
    MQ_AUTO_REORG_TIME_LENGTH 4 X'00000004'
    MQ_BATCH_INTERFACE_ID_LENGTH 8 X'00000008'
    MQ_BRIDGE_NAME_LENGTH 24 X'00000018'
    MQ_CANCEL_CODE_LENGTH 4 X'00000004'
    MQ_CF_STRUC_DESC_LENGTH 64 X'00000040'
    MQ_CF_STRUC_NAME_LENGTH 12 X'0000000C'
    MQ_CHANNEL_DATE_LENGTH 12 X'0000000C'
    MQ_CHANNEL_DESC_LENGTH 64 X'00000040'
    MQ_CHANNEL_NAME_LENGTH 20 X'00000014'
    MQ_CHANNEL_TIME_LENGTH 8 X'00000008'
    MQ_CHINIT_SERVICE_PARM_LENGTH 32 X'00000020'
    MQ_CICS_FILE_NAME_LENGTH 8 X'00000008'
    MQ_CLUSTER_NAME_LENGTH 48 X'00000030'
    MQ_CONN_NAME_LENGTH 264 X'00000108'
    MQ_CONN_TAG_LENGTH 128 X'00000080'
    MQ_CONNECTION_ID_LENGTH 24 X'00000018'
    MQ_CORREL_ID_LENGTH 24 X'00000018'
    MQ_CREATION_DATE_LENGTH 12 X'0000000C'
    MQ_CREATION_TIME_LENGTH 8 X'00000008'
    MQ_DATE_LENGTH 12 X'0000000C'
    MQ_DISTINGUISHED_NAME_LENGTH 1024 X'00000400'
    MQ_DNS_GROUP_NAME_LENGTH 18 X'00000012'
    MQ_EXIT_DATA_LENGTH 32 X'00000020'
    MQ_EXIT_INFO_NAME_LENGTH 48 X'00000030'
    MQ_EXIT_NAME_LENGTH (value differs by platform or version)
    MQ_EXIT_PD_AREA_LENGTH 48 X'00000030'
    MQ_EXIT_USER_AREA_LENGTH 16 X'00000010'
    MQ_FACILITY_LENGTH 8 X'00000008'
    MQ_FACILITY_LIKE_LENGTH 4 X'00000004'
    MQ_FORMAT_LENGTH 8 X'00000008'
    MQ_FUNCTION_LENGTH 4 X'00000004'
    MQ_GROUP_ID_LENGTH 24 X'00000018'
    MQ_LDAP_PASSWORD_LENGTH 32 X'00000020'
    MQ_LISTENER_NAME_LENGTH 48 X'00000030'
    MQ_LISTENER_DESC_LENGTH 64 X'00000040'
    MQ_LOCAL_ADDRESS_LENGTH 48 X'00000030'
    MQ_LTERM_OVERRIDE_LENGTH 8 X'00000008'
    MQ_LU_NAME_LENGTH 8 X'00000008'
    MQ_LUWID_LENGTH 16 X'00000010'
    MQ_MAX_EXIT_NAME_LENGTH 128 X'00000080'
    MQ_MAX_MCA_USER_ID_LENGTH 64 X'00000040'
    MQ_MAX_PROPERTY_NAME_LENGTH 4095 X'00000FFF'
    MQ_MAX_USER_ID_LENGTH 64 X'00000040'
    MQ_MCA_JOB_NAME_LENGTH 28 X'0000001C'
    MQ_MCA_NAME_LENGTH 20 X'00000014'
    MQ_MCA_USER_DATA_LENGTH 32 X'00000020'
    MQ_MCA_USER_ID_LENGTH (value differs by platform or version)
    MQ_MFS_MAP_NAME_LENGTH 8 X'00000008'
    MQ_MODE_NAME_LENGTH 8 X'00000008'
    MQ_MSG_HEADER_LENGTH 4000 X'00000FA0'
    MQ_MSG_ID_LENGTH 24 X'00000018'
    MQ_MSG_TOKEN_LENGTH 16 X'00000010'
    MQ_NAMELIST_DESC_LENGTH 64 X'00000040'
    MQ_NAMELIST_NAME_LENGTH 48 X'00000030'
    MQ_OBJECT_INSTANCE_ID_LENGTH 24 X'00000018'
    MQ_OBJECT_NAME_LENGTH 48 X'00000030'
    MQ_PASS_TICKET_APPL_LENGTH 8 X'00000008'
    MQ_PASSWORD_LENGTH 12 X'0000000C'
    MQ_PROCESS_APPL_ID_LENGTH 256 X'00000100'
    MQ_PROCESS_DESC_LENGTH 64 X'00000040'
    MQ_PROCESS_ENV_DATA_LENGTH 128 X'00000080'
    MQ_PROCESS_NAME_LENGTH 48 X'00000030'
    MQ_PROCESS_USER_DATA_LENGTH 128 X'00000080'
    MQ_PROGRAM_NAME_LENGTH 20 X'00000014'
    MQ_PUT_APPL_NAME_LENGTH 28 X'0000001C'
    MQ_PUT_DATE_LENGTH 8 X'00000008'
    MQ_PUT_TIME_LENGTH 8 X'00000008'
    MQ_Q_DESC_LENGTH 64 X'00000040'
    MQ_Q_MGR_DESC_LENGTH 64 X'00000040'
    MQ_Q_MGR_IDENTIFIER_LENGTH 48 X'00000030'
    MQ_Q_MGR_NAME_LENGTH 48 X'00000030'
    MQ_Q_NAME_LENGTH 48 X'00000030'
    MQ_QSG_NAME_LENGTH 4 X'00000004'
    MQ_REMOTE_SYS_ID_LENGTH 4 X'00000004'
    MQ_SECURITY_ID_LENGTH 40 X'00000028'
    MQ_SELECTOR_LENGTH 10240 X'00002800'
    MQ_SERVICE_ARGS_LENGTH 255 X'000000FF'
    MQ_SERVICE_COMMAND_LENGTH 255 X'000000FF'
    MQ_SERVICE_DESC_LENGTH 64 X'00000040'
    MQ_SERVICE_NAME_LENGTH 32 X'00000020'
    MQ_SERVICE_PATH_LENGTH 255 X'000000FF'
    MQ_SERVICE_STEP_LENGTH 8 X'00000008'
    MQ_SHORT_CONN_NAME_LENGTH 20 X'00000014'
    MQ_SHORT_DNAME_LENGTH 256 X'00000100'
    MQ_SSL_CIPHER_SPEC_LENGTH 32 X'00000020'
    MQ_SSL_CRYPTO_HARDWARE_LENGTH 256 X'00000100'
    MQ_SSL_HANDSHAKE_STAGE_LENGTH 32 X'00000020'
    MQ_SSL_KEY_LIBRARY_LENGTH 44 X'0000002C'
    MQ_SSL_KEY_MEMBER_LENGTH 8 X'00000008'
    MQ_SSL_KEY_REPOSITORY_LENGTH 256 X'00000100'
    MQ_SSL_PEER_NAME_LENGTH 1024 X'00000400'
    MQ_SSL_SHORT_PEER_NAME_LENGTH 256 X'00000100'
    MQ_START_CODE_LENGTH 4 X'00000004'
    MQ_STORAGE_CLASS_DESC_LENGTH 64 X'00000040'
    MQ_STORAGE_CLASS_LENGTH 8 X'00000008'
    MQ_SUB_IDENTITY_LENGTH 128 X'00000080'
    MQ_SUB_POINT_LENGTH 128 X'00000080'
    MQ_TCP_NAME_LENGTH 8 X'00000008'
    MQ_TIME_LENGTH 8 X'00000008'
    MQ_TOPIC_DESC_LENGTH 64 X'00000040'
    MQ_TOPIC_NAME_LENGTH 48 X'00000030'
    MQ_TOPIC_STR_LENGTH 10240 X'00002800'
    MQ_TOTAL_EXIT_DATA_LENGTH 999 X'000003E7'
    MQ_TOTAL_EXIT_NAME_LENGTH 999 X'000003E7'
    MQ_TP_NAME_LENGTH 64 X'00000040'
    MQ_TPIPE_NAME_LENGTH 8 X'00000008'
    MQ_TRAN_INSTANCE_ID_LENGTH 16 X'00000010'
    MQ_TRANSACTION_ID_LENGTH 4 X'00000004'
    MQ_TRIGGER_DATA_LENGTH 64 X'00000040'
    MQ_TRIGGER_PROGRAM_NAME_LENGTH 8 X'00000008'
    MQ_TRIGGER_TERM_ID_LENGTH 4 X'00000004'
    MQ_TRIGGER_TRANS_ID_LENGTH 4 X'00000004'
    MQ_USER_ID_LENGTH 12 X'0000000C'
    MQ_XCF_GROUP_NAME_LENGTH 8 X'00000008'
    MQ_XCF_MEMBER_NAME_LENGTH 16 X'00000010'

    MQ (Command format String Lengths)

    MQ_ARCHIVE_PFX_LENGTH 36 X'00000024'
    MQ_ARCHIVE_UNIT_LENGTH 8 X'00000008'
    MQ_ASID_LENGTH 4 X'00000004'
    MQ_AUTH_PROFILE_NAME_LENGTH 48 X'00000030'
    MQ_CF_LEID_LENGTH 12 X'0000000C'
    MQ_COMMAND_MQSC_LENGTH 32768 X'00008000'
    MQ_DATA_SET_NAME_LENGTH 44 X'0000002C'
    MQ_DB2_NAME_LENGTH 4 X'00000004'
    MQ_DSG_NAME_LENGTH 8 X'00000008'
    MQ_ENTITY_NAME_LENGTH 64 X'00000040'
    MQ_ENV_INFO_LENGTH 96 X'00000060'
    MQ_IP_ADDRESS_LENGTH 48 X'00000030'
    MQ_LOG_CORREL_ID_LENGTH 8 X'00000008'
    MQ_LOG_EXTENT_NAME_LENGTH 24 X'00000018'
    MQ_LOG_PATH_LENGTH 1024 X'00000400'
    MQ_LRSN_LENGTH 12 X'0000000C'
    MQ_ORIGIN_NAME_LENGTH 8 X'00000008'
    MQ_PSB_NAME_LENGTH 8 X'00000008'
    MQ_PST_ID_LENGTH 8 X'00000008'
    MQ_Q_MGR_CPF_LENGTH 4 X'00000004'
    MQ_RESPONSE_ID_LENGTH 24 X'00000018'
    MQ_RBA_LENGTH 12 X'0000000C'
    MQ_SECURITY_PROFILE_LENGTH 40 X'00000028'
    MQ_SERVICE_COMPONENT_LENGTH 48 X'00000030'
    MQ_SUB_NAME_LENGTH 10240 X'00002800'
    MQ_SYSP_SERVICE_LENGTH 32 X'00000020'
    MQ_SYSTEM_NAME_LENGTH 8 X'00000008'
    MQ_TASK_NUMBER_LENGTH 8 X'00000008'
    MQ_TPIPE_PFX_LENGTH 4 X'00000004'
    MQ_UOW_ID_LENGTH 256 X'00000100'
    MQ_USER_DATA_LENGTH 10240 X'00002800'
    MQ_VOLSER_LENGTH 6 X'00000006'
    0 (0 Ratings)
    [ 491 views ] Leave a Comment

    IBM Websphere MQ - MQRC Reason Codes - Middleware News

    Tuesday, June 19, 2012, 12:40 PM
    Categories: WebSphere MQ
    Posted By: Karthick

    MQRC_* (Reason Codes)

    <td class="entry" valign="top"
    MQRC_NONE 0 X'00000000'
    MQRC_APPL_FIRST 900 X'00000384'
    MQRC_APPL_LAST 999 X'000003E7'
    MQRC_ALIAS_BASE_Q_TYPE_ERROR 2001 X'000007D1'
    MQRC_ALREADY_CONNECTED 2002 X'000007D2'
    MQRC_BACKED_OUT 2003 X'000007D3'
    MQRC_BUFFER_ERROR 2004 X'000007D4'
    MQRC_BUFFER_LENGTH_ERROR 2005 X'000007D5'
    MQRC_CHAR_ATTR_LENGTH_ERROR 2006 X'000007D6'
    MQRC_CHAR_ATTRS_ERROR 2007 X'000007D7'
    MQRC_CHAR_ATTRS_TOO_SHORT 2008 X'000007D8'
    MQRC_CONNECTION_BROKEN 2009 X'000007D9'
    MQRC_DATA_LENGTH_ERROR 2010 X'000007DA'
    MQRC_DYNAMIC_Q_NAME_ERROR 2011 X'000007DB'
    MQRC_ENVIRONMENT_ERROR 2012 X'000007DC'
    MQRC_EXPIRY_ERROR 2013 X'000007DD'
    MQRC_FEEDBACK_ERROR 2014 X'000007DE'
    MQRC_GET_INHIBITED 2016 X'000007E0'
    MQRC_HANDLE_NOT_AVAILABLE 2017 X'000007E1'
    MQRC_HCONN_ERROR 2018 X'000007E2'
    MQRC_HOBJ_ERROR 2019 X'000007E3'
    MQRC_INHIBIT_VALUE_ERROR 2020 X'000007E4'
    MQRC_INT_ATTR_COUNT_ERROR 2021 X'000007E5'
    MQRC_INT_ATTR_COUNT_TOO_SMALL 2022 X'000007E6'
    MQRC_INT_ATTRS_ARRAY_ERROR 2023 X'000007E7'
    MQRC_SYNCPOINT_LIMIT_REACHED 2024 X'000007E8'
    MQRC_MAX_CONNS_LIMIT_REACHED 2025 X'000007E9'
    MQRC_MD_ERROR 2026 X'000007EA'
    MQRC_MISSING_REPLY_TO_Q 2027 X'000007EB'
    MQRC_MSG_TYPE_ERROR 2029 X'000007ED'
    MQRC_MSG_TOO_BIG_FOR_Q 2030 X'000007EE'
    MQRC_MSG_TOO_BIG_FOR_Q_MGR 2031 X'000007EF'
    MQRC_NO_MSG_AVAILABLE 2033 X'000007F1'
    MQRC_NO_MSG_UNDER_CURSOR 2034 X'000007F2'
    MQRC_NOT_AUTHORIZED 2035 X'000007F3'
    MQRC_NOT_OPEN_FOR_BROWSE 2036 X'000007F4'
    MQRC_NOT_OPEN_FOR_INPUT 2037 X'000007F5'
    MQRC_NOT_OPEN_FOR_INQUIRE 2038 X'000007F6'
    MQRC_NOT_OPEN_FOR_OUTPUT 2039 X'000007F7'
    MQRC_NOT_OPEN_FOR_SET 2040 X'000007F8'
    MQRC_OBJECT_CHANGED 2041 X'000007F9'
    MQRC_OBJECT_IN_USE 2042 X'000007FA'
    MQRC_OBJECT_TYPE_ERROR 2043 X'000007FB'
    MQRC_OD_ERROR 2044 X'000007FC'
    MQRC_OPTION_NOT_VALID_FOR_TYPE 2045 X'000007FD'
    MQRC_OPTIONS_ERROR 2046 X'000007FE'
    MQRC_PERSISTENCE_ERROR 2047 X'000007FF'
    MQRC_PERSISTENT_NOT_ALLOWED 2048 X'00000800'
    MQRC_PRIORITY_EXCEEDS_MAXIMUM 2049 X'00000801'
    MQRC_PRIORITY_ERROR 2050 X'00000802'
    MQRC_PUT_INHIBITED 2051 X'00000803'
    MQRC_Q_DELETED 2052 X'00000804'
    MQRC_Q_FULL 2053 X'00000805'
    MQRC_Q_NOT_EMPTY 2055 X'00000807'
    MQRC_Q_SPACE_NOT_AVAILABLE 2056 X'00000808'
    MQRC_Q_TYPE_ERROR 2057 X'00000809'
    MQRC_Q_MGR_NAME_ERROR 2058 X'0000080A'
    MQRC_Q_MGR_NOT_AVAILABLE 2059 X'0000080B'
    MQRC_REPORT_OPTIONS_ERROR 2061 X'0000080D'
    MQRC_SECOND_MARK_NOT_ALLOWED 2062 X'0000080E'
    MQRC_SECURITY_ERROR 2063 X'0000080F'
    MQRC_SELECTOR_COUNT_ERROR 2065 X'00000811'
    MQRC_SELECTOR_LIMIT_EXCEEDED 2066 X'00000812'
    MQRC_SELECTOR_ERROR 2067 X'00000813'
    MQRC_SELECTOR_NOT_FOR_TYPE 2068 X'00000814'
    MQRC_SIGNAL_OUTSTANDING 2069 X'00000815'
    MQRC_SIGNAL_REQUEST_ACCEPTED 2070 X'00000816'
    MQRC_STORAGE_NOT_AVAILABLE 2071 X'00000817'
    MQRC_SYNCPOINT_NOT_AVAILABLE 2072 X'00000818'
    MQRC_TRIGGER_CONTROL_ERROR 2075 X'0000081B'
    MQRC_TRIGGER_DEPTH_ERROR 2076 X'0000081C'
    MQRC_TRIGGER_MSG_PRIORITY_ERR 2077 X'0000081D'
    MQRC_TRIGGER_TYPE_ERROR 2078 X'0000081E'
    MQRC_TRUNCATED_MSG_ACCEPTED 2079 X'0000081F'
    MQRC_TRUNCATED_MSG_FAILED 2080 X'00000820'
    MQRC_UNKNOWN_ALIAS_BASE_Q 2082 X'00000822'
    MQRC_UNKNOWN_OBJECT_NAME 2085 X'00000825'
    MQRC_UNKNOWN_OBJECT_Q_MGR 2086 X'00000826'
    MQRC_UNKNOWN_REMOTE_Q_MGR 2087 X'00000827'
    MQRC_WAIT_INTERVAL_ERROR 2090 X'0000082A'
    MQRC_XMIT_Q_TYPE_ERROR 2091 X'0000082B'
    MQRC_XMIT_Q_USAGE_ERROR 2092 X'0000082C'
    MQRC_NOT_OPEN_FOR_PASS_ALL 2093 X'0000082D'
    MQRC_NOT_OPEN_FOR_PASS_IDENT 2094 X'0000082E'
    MQRC_NOT_OPEN_FOR_SET_ALL 2095 X'0000082F'
    MQRC_NOT_OPEN_FOR_SET_IDENT 2096 X'00000830'
    MQRC_CONTEXT_HANDLE_ERROR 2097 X'00000831'
    MQRC_CONTEXT_NOT_AVAILABLE 2098 X'00000832'
    MQRC_SIGNAL1_ERROR 2099 X'00000833'
    MQRC_OBJECT_ALREADY_EXISTS 2100 X'00000834'
    MQRC_OBJECT_DAMAGED 2101 X'00000835'
    MQRC_RESOURCE_PROBLEM 2102 X'00000836'
    MQRC_ANOTHER_Q_MGR_CONNECTED 2103 X'00000837'
    MQRC_UNKNOWN_REPORT_OPTION 2104 X'00000838'
    MQRC_STORAGE_CLASS_ERROR 2105 X'00000839'
    MQRC_COD_NOT_VALID_FOR_XCF_Q 2106 X'0000083A'
    MQRC_XWAIT_CANCELED 2107 X'0000083B'
    MQRC_XWAIT_ERROR 2108 X'0000083C'
    MQRC_SUPPRESSED_BY_EXIT 2109 X'0000083D'
    MQRC_FORMAT_ERROR 2110 X'0000083E'
    MQRC_SOURCE_CCSID_ERROR 2111 X'0000083F'
    MQRC_SOURCE_INTEGER_ENC_ERROR 2112 X'00000840'
    MQRC_SOURCE_DECIMAL_ENC_ERROR 2113 X'00000841'
    MQRC_SOURCE_FLOAT_ENC_ERROR 2114 X'00000842'
    MQRC_TARGET_CCSID_ERROR 2115 X'00000843'
    MQRC_TARGET_INTEGER_ENC_ERROR 2116 X'00000844'
    MQRC_TARGET_DECIMAL_ENC_ERROR 2117 X'00000845'
    MQRC_TARGET_FLOAT_ENC_ERROR 2118 X'00000846'
    MQRC_NOT_CONVERTED 2119 X'00000847'
    MQRC_CONVERTED_MSG_TOO_BIG 2120 X'00000848'
    MQRC_TRUNCATED 2120 X'00000848'
    MQRC_NO_EXTERNAL_PARTICIPANTS 2121 X'00000849'
    MQRC_PARTICIPANT_NOT_AVAILABLE 2122 X'0000084A'
    MQRC_OUTCOME_MIXED 2123 X'0000084B'
    MQRC_OUTCOME_PENDING 2124 X'0000084C'
    MQRC_BRIDGE_STARTED 2125 X'0000084D'
    MQRC_BRIDGE_STOPPED 2126 X'0000084E'
    MQRC_ADAPTER_STORAGE_SHORTAGE 2127 X'0000084F'
    MQRC_UOW_IN_PROGRESS 2128 X'00000850'
    MQRC_ADAPTER_CONN_LOAD_ERROR 2129 X'00000851'
    MQRC_ADAPTER_SERV_LOAD_ERROR 2130 X'00000852'
    MQRC_ADAPTER_DEFS_ERROR 2131 X'00000853'
    MQRC_ADAPTER_DEFS_LOAD_ERROR 2132 X'00000854'
    MQRC_ADAPTER_CONV_LOAD_ERROR 2133 X'00000855'
    MQRC_BO_ERROR 2134 X'00000856'
    MQRC_DH_ERROR 2135 X'00000857'
    MQRC_MULTIPLE_REASONS 2136 X'00000858'
    MQRC_OPEN_FAILED 2137 X'00000859'
    MQRC_ADAPTER_DISC_LOAD_ERROR 2138 X'0000085A'
    MQRC_CNO_ERROR 2139 X'0000085B'
    MQRC_CICS_WAIT_FAILED 2140 X'0000085C'
    MQRC_DLH_ERROR 2141 X'0000085D'
    MQRC_HEADER_ERROR 2142 X'0000085E'
    MQRC_SOURCE_LENGTH_ERROR 2143 X'0000085F'
    MQRC_TARGET_LENGTH_ERROR 2144 X'00000860'
    MQRC_SOURCE_BUFFER_ERROR 2145 X'00000861'
    MQRC_TARGET_BUFFER_ERROR 2146 X'00000862'
    MQRC_IIH_ERROR 2148 X'00000864'
    MQRC_PCF_ERROR 2149 X'00000865'
    MQRC_DBCS_ERROR 2150 X'00000866'
    MQRC_OBJECT_NAME_ERROR 2152 X'00000868'
    MQRC_OBJECT_Q_MGR_NAME_ERROR 2153 X'00000869'
    MQRC_RECS_PRESENT_ERROR 2154 X'0000086A'
    MQRC_OBJECT_RECORDS_ERROR 2155 X'0000086B'
    MQRC_RESPONSE_RECORDS_ERROR 2156 X'0000086C'
    MQRC_ASID_MISMATCH 2157 X'0000086D'
    MQRC_PMO_RECORD_FLAGS_ERROR 2158 X'0000086E'
    MQRC_PUT_MSG_RECORDS_ERROR 2159 X'0000086F'
    MQRC_CONN_ID_IN_USE 2160 X'00000870'
    MQRC_Q_MGR_QUIESCING 2161 X'00000871'
    MQRC_Q_MGR_STOPPING 2162 X'00000872'
    MQRC_DUPLICATE_RECOV_COORD 2163 X'00000873'
    MQRC_PMO_ERROR 2173 X'0000087D'
    MQRC_API_EXIT_NOT_FOUND 2182 X'00000886'
    MQRC_API_EXIT_LOAD_ERROR 2183 X'00000887'
    MQRC_REMOTE_Q_NAME_ERROR 2184 X'00000888'
    MQRC_INCONSISTENT_PERSISTENCE 2185 X'00000889'
    MQRC_GMO_ERROR 2186 X'0000088A'
    MQRC_CICS_BRIDGE_RESTRICTION 2187 X'0000088B'
    MQRC_STOPPED_BY_CLUSTER_EXIT 2188 X'0000088C'
    MQRC_CLUSTER_RESOLUTION_ERROR 2189 X'0000088D'
    MQRC_CONVERTED_STRING_TOO_BIG 2190 X'0000088E'
    MQRC_TMC_ERROR 2191 X'0000088F'
    MQRC_PAGESET_FULL 2192 X'00000890'
    MQRC_STORAGE_MEDIUM_FULL 2192 X'00000890'
    MQRC_PAGESET_ERROR 2193 X'00000891'
    MQRC_NAME_NOT_VALID_FOR_TYPE 2194 X'00000892'
    MQRC_UNEXPECTED_ERROR 2195 X'00000893'
    MQRC_UNKNOWN_XMIT_Q 2196 X'00000894'
    MQRC_UNKNOWN_DEF_XMIT_Q 2197 X'00000895'
    MQRC_DEF_XMIT_Q_TYPE_ERROR 2198 X'00000896'
    MQRC_DEF_XMIT_Q_USAGE_ERROR 2199 X'00000897'
    MQRC_MSG_MARKED_BROWSE_CO_OP 2200 X'00000898'
    MQRC_NAME_IN_USE 2201 X'00000899'
    MQRC_CONNECTION_QUIESCING 2202 X'0000089A'
    MQRC_CONNECTION_STOPPING 2203 X'0000089B'
    MQRC_ADAPTER_NOT_AVAILABLE 2204 X'0000089C'
    MQRC_MSG_ID_ERROR 2206 X'0000089E'
    MQRC_CORREL_ID_ERROR 2207 X'0000089F'
    MQRC_FILE_SYSTEM_ERROR 2208 X'000008A0'
    MQRC_NO_MSG_LOCKED 2209 X'000008A1'
    MQRC_SOAP_DOTNET_ERROR 2210 X'000008A2'
    MQRC_SOAP_AXIS_ERROR 2211 X'000008A3'
    MQRC_SOAP_URL_ERROR 2212 X'000008A4'
    MQRC_FILE_NOT_AUDITED 2216 X'000008A8'
    MQRC_CONNECTION_NOT_AUTHORIZED 2217 X'000008A9'
    MQRC_MSG_TOO_BIG_FOR_CHANNEL 2218 X'000008AA'
    MQRC_CALL_IN_PROGRESS 2219 X'000008AB'
    MQRC_RMH_ERROR 2220 X'000008AC'
    MQRC_Q_MGR_ACTIVE 2222 X'000008AE'
    MQRC_Q_MGR_NOT_ACTIVE 2223 X'000008AF'
    MQRC_Q_DEPTH_HIGH 2224 X'000008B0'
    MQRC_Q_DEPTH_LOW 2225 X'000008B1'
    MQRC_Q_SERVICE_INTERVAL_HIGH 2226 X'000008B2'
    MQRC_Q_SERVICE_INTERVAL_OK 2227 X'000008B3'
    MQRC_RFH_HEADER_FIELD_ERROR 2228 X'000008B4'
    MQRC_RAS_PROPERTY_ERROR 2229 X'000008B5'
    MQRC_UNIT_OF_WORK_NOT_STARTED 2232 X'000008B8'
    MQRC_CHANNEL_AUTO_DEF_OK 2233 X'000008B9'
    MQRC_CHANNEL_AUTO_DEF_ERROR 2234 X'000008BA'
    MQRC_CFH_ERROR 2235 X'000008BB'
    MQRC_CFIL_ERROR 2236 X'000008BC'
    MQRC_CFIN_ERROR 2237 X'000008BD'
    MQRC_CFSL_ERROR 2238 X'000008BE'
    MQRC_CFST_ERROR 2239 X'000008BF'
    MQRC_INCOMPLETE_GROUP 2241 X'000008C1'
    MQRC_INCOMPLETE_MSG 2242 X'000008C2'
    MQRC_INCONSISTENT_CCSIDS 2243 X'000008C3'
    MQRC_INCONSISTENT_ENCODINGS 2244 X'000008C4'
    MQRC_INCONSISTENT_UOW 2245 X'000008C5'
    MQRC_INVALID_MSG_UNDER_CURSOR 2246 X'000008C6'
    MQRC_MATCH_OPTIONS_ERROR 2247 X'000008C7'
    MQRC_MDE_ERROR 2248 X'000008C8'
    MQRC_MSG_FLAGS_ERROR 2249 X'000008C9'
    MQRC_MSG_SEQ_NUMBER_ERROR 2250 X'000008CA'
    MQRC_OFFSET_ERROR 2251 X'000008CB'

    [Edited By Moderator]

    0 (0 Ratings)
    [ 5706 views ] Leave a Comment

    IBM Announcement: End of Support for WebSphere MQ V6

    Tuesday, June 19, 2012, 12:11 PM
    Categories: WebSphere MQ
    Posted By: Karthick

    IBM Announcement: End of Support for WebSphere MQ V6 - Middleware News

    On September 30 2012, IBM will withdraw support for WebSphere MQ v6.0 under the International Program License Agreement (IPLA). The replacement product is WebSphere MQ for Multiplatforms V7.x.

    Content

    Support will be withdrawn for all Websphere MQ components including Server, Client and MQ Explorer of following platforms :

    Product Name Version General
    availability
    End of
    Support
    WebSphere MQ for AIX 6.0.x 24 Jun 2005 30 Sep 2012
    WebSphere MQ for HP-UX (Itanium) 6.0.x 02 Dec 2005 30 Sep 2012
    WebSphere MQ for HP-UX (PA-RISC) 6.0.x 24 Jun 2005 30 Sep 2012
    WebSphere MQ for iSeries 6.0.x 24 Jun 2005 30 Sep 2012
    WebSphere MQ for Linux (POWER) 6.0.x 24 Jun 2005 30 Sep 2012
    WebSphere MQ for Linux (x86) 6.0.x 24 Jun 2005 30 Sep 2012
    WebSphere MQ for Linux (x86-64) 6.0.x 02 Dec 2005 30 Sep 2012
    WebSphere MQ for Linux (zSeries) 6.0.x 24 Jun 2005 30 Sep 2012
    WebSphere MQ for Linux (zSeries s390x) 6.0.x 02 Dec 2005 30 Sep 2012
    WebSphere MQ for Solaris (SPARC) 6.0.x 24 Jun 2005 30 Sep 2012
    WebSphere MQ for Solaris (x86-64) 6.0.x 02 Dec 2005 30 Sep 2012
    WebSphere MQ for Windows 6.0.x 24 Jun 2005 30 Sep 2012
    WebSphere MQ for z/OS 6.0.x 24 Jun 2005 30 Sep 2012
    0 (0 Ratings)
    [ 602 views ] Leave a Comment

    Processing messages with the WebSphere Application Server V7 and V8 WebSphere MQ messaging provider activation specifications

    Sunday, May 27, 2012, 10:09 AM
    Categories: WebSphere MQ
    Posted By: Karthick

    IBM® WebSphere® Application Server V7 and V8 provide support for asynchronous messaging based on the Java Message Service (JMS) specification. Using the WebSphere MQ messaging provider, you can write message-driven beans that listen on a WebSphere MQ destination (either a message queue or a topic). When a message arrives on the destination, the message-driven bean's onMessage() method is invoked to process the message.

    In WebSphere Application Server V7 and V8, the WebSphere MQ messaging provider supports the use of activation specifications to monitor destinations hosted by WebSphere MQ queue managers. This article shows how activation specifications connect to WebSphere MQ on distributed platforms, describes the mechanism used to monitor the destinations looking for messages, and then shows how message-driven beans are invoked after a suitable message has been detected. The article assumes a basic knowledge of JMS and WebSphere MQ.

    Activation specifications

    In general terms, J2C activation specifications are administered objects that contain information about how to connect to a JMS provider, along with details of the destination on that JMS provider that will be monitored for messages. When deploying an application that contains a message-driven bean, you need to specify the activation specification that the message-driven beans will use. When the activation specification starts up, it connects to a JMS provider, opens the JMS destination, and then monitors it looking for messages.

    Figures 1 and 2 below show a sample WebSphere MQ activation specification that has been defined using the activation specification panel in the WebSphere Application Server Integrated Solutions Console. When this activation specification starts up, it makes a BINDINGS mode connection to a local WebSphere MQ queue manager called pault, opens the destination jms/TestQueue, and then starts monitoring this destination for messages.


    Figure 1. Specifying the queue manager name and transport type
    Specifying the queue manager name and transport type

    Figure 2. Specifying the JMS destination that an activation specification will monitor
    Specifying the JMS destination that an activation specification will monitor

    Activation specifications can be configured to use message selectors, which enables them to only pass messages that meet the selection criteria to message-driven beans. In Figure 2 above, no message selector has been specified, and therefore all messages that arrive on the destination are suitable for processing by this activation specification.

    Once an activation specification finds a suitable message, it schedules a piece of work within the application server to process it. Each message requires a JMS server session in order to run, and multiple messages can be processed at the same time.

    Each activation specification has an associated server session pool, and its size controls the number of messages that can be processed concurrently by an activation specification. The default size of the server session pool is 10, which means that up to 10 messages can be processed at the same time by a single activation specification. To change the server session pool size, modify the activation specification advanced property Maximum server sessions, as shown in Figure 3:


    Figure 3. Specifying how many messages can be processed concurrently
    Specifying how many messages can be processed concurrently

    Detecting messages

    The mechanism that an activation specification uses to detect messages on JMS destinations hosted on a WebSphere MQ queue manager varies depending on the WebSphere MQ messaging provider mode that is being used, as described below.

    WebSphere MQ messaging provider normal mode

    Activation specifications use the WebSphere MQ messaging provider normal mode if they are connecting to a WebSphere MQ V7 queue manager and they have the Provider versionproperty set to either unspecified (the default value) or 7. In this mode of operation, the activation specification takes advantage of a number of the features of WebSphere MQ V7 when connecting to a queue manager and getting messages. When it starts up, the activation specification:

    1. Creates a connection to the WebSphere MQ queue manager it has been set up to use.
    2. If the activation specification is configured to use a Queue Destination, it opens the queue using the WebSphere MQ API call MQOPEN.
    3. If the activation specification has been configured to use a Topic Destination, it issues a WebSphere MQ API MQSUB call to subscribe to the appropriate topic.
    4. After the queue has been opened or the topic subscribed to, the activation specification uses the WebSphere MQ API call MQCB to register a callback. The callback is set up with the following WebSphere MQ GetMessageOptions:
      • MQGMO_BROWSE_FIRST
      • MQGMO_UNMARKED_BROWSE_MSG
      • MQGMO_MARK_BROWSE_CO_OP
    5. After the callback has been registered, the activation specification issues a WebSphere MQ MQCTL API call, which tells the queue manager that the activation specification is ready to start receiving messages.

    Now, when a suitable message arrives on the queue that the activation specification is monitoring, or is published on the topic that the activation specification has subscribed to, the queue manager marks the message to prevent any other activation specifications from seeing it, and then passes details of the message to the activation specification via the callback that was set up earlier.

    WebSphere MQ messaging provider migration mode

    The other way that activation specifications can connect to a WebSphere MQ queue manager is by using the WebSphere MQ messaging provider migration mode. This mode is used if one of the following conditions is true:

    • The activation specification is configured to connect to a WebSphere MQ V6 queue manager.
    • The activation specification is configured to connect to a WebSphere MQ V7 queue manager, and has the Provider Versionproperty set to 6.
    • The activation specification has been configured to connect to a WebSphere MQ V7 queue manager using the CLIENT transport, and is using a WebSphere MQ channel that has the Sharing Conversations (SHARECNV) property set to 0.

    When the activation specification starts up in migration mode, it:

    1. Creates a connection to the WebSphere MQ queue manager it has been set up to use.
    2. If the activation specification has been configured to monitor a Queue Destination, it issues an MQOPEN API call to open the queue.
    3. If the activation specification has been configured to use a Topic Destination, it:
      • Opens a subscription for the topic.
      • Checks the values of the activation specification Broker Properties Broker connection consumer subscription queue and Broker durable subscriber connection consumer queue to see which WebSphere MQ queue the Broker will publish messages for this activation specification to.
      • Calls the WebSphere MQ API MQOPEN to open the appropriate subscription queue.
    4. Once the queue has been opened on the queue manager, the activation specification browses the queue looking for messages by issuing a number of MQGET API calls. The activation specification uses a combination of the WebSphere MQ GetMessageOptions MQGMO_BROWSE_FIRST and MQGMO_BROWSE_NEXT to scan the queue from top to bottom.

    Processing messages

    When an activation specification has detected a message on a destination (either because a WebSphere MQ V7 queue manager has passed back information about a message via a callback, or because the activation specification has browsed a suitable message), it:

    1. Constructs a message reference that represents the message.
    2. Gets a server session from the activation specification server session pool.
    3. Loads up the server session with the message reference.
    4. Schedules a piece of work with the application server Work Manager.

    The activation specification then goes back to looking for more messages.

    Getting server sessions

    As mentioned earlier, activation specifications will process up to 10 messages concurrently by default. What happens if an activation specification tries to process a message and all 10 server sessions are already busy processing messages? In this situation, the activation specification will block until a server session becomes free. As soon as a server session is available, the activation specification loads it up with the message reference, and then schedules a new piece of work so the server session can run again.

    Scheduling work

    Once the activation specification loads a server session with a message reference, it schedules some work so that the message can be processed. What happens to the work? The Work Manager:

    1. Gets a thread from the WebSphere Application Server WebSphere MQ messaging provider Resource Adapter thread pool. The name of this thread pool is WMQJCAResourceAdapter.
    2. Runs the piece of work on this thread.

    After the work has been scheduled, the application server Work Manager will run this piece of work at some point in the future. The work, when started:

    1. Starts either a local or global (XA) transaction, depending on whether the message-driven bean requires XA transactions or not (specified in the message-driven bean's deployment descriptor).
    2. If this is the first time the server session has been used, it:
      • Creates a new connection to WebSphere MQ.
      • Issues an MQOPEN API call to open the queue where the message resides.
    3. Gets the message from WebSphere MQ by issuing a destructive MQGET API call.
    4. Runs the message-driven bean's onMessage() method.
    5. Once onMessage() has completed, the server session completes the local or global transaction before exiting.

    To improve performance, the connection to the queue manager that the server session uses is left open after the message has been processed and the work completed. Then, the next time the server session is used to process a message, it need not reconnect to WebSphere MQ and reopen the queue containing the message. By default, unused server sessions associated with activation specifications are left open for 30 minutes before being closed off. You can later this timeout period by modifying the value of the activation specification advanced property Server session pool timeout, as shown in Figure 4 below

    On a lightly loaded system, the time between the piece of work being scheduled and the Work Manager starting the work can be just a few milliseconds. On busy systems, there may be a lengthy delay before the work is actually started. There are two possible reasons for a delay:

    • There were no free threads in the WMQJCAResourceAdapter thread pool to run the work.
    • The Work Manager was able to get a thread from the thread pool, and but then could not start the work because the application server was too busy.

    The Work Manager records when a piece of work was scheduled, and when it starts the work, it checks how much time has elapsed since the activation specification scheduled the work. By default, the activation specification expects the work to be started within 10 seconds of it being scheduled. If more than 10 seconds elapse before the Work Manager starts the work, then a WorkRejected exception is returned back to the activation specification, causing exceptions similar to the one below to appear in the application server SystemErr.log:

    Exception in thread "WMQJCAResourceAdapter : 1" 
    java.lang.RuntimeException: javax.resource.spi.work.WorkRejectedException: Work timed
    out (id=4), error code: 1 : : : : : : : : : : : : : : : Caused by: javax.resource.spi.work.WorkRejectedException:
    Work timed out (id=4), error code: 1

    When an exception like this one occurs, the message in the Message Reference will have been "unmarked" by the queue manager, so that it can be reprocessed. You can change this 10-second time limit on the activation specification Advanced properties panel using Start timeout, as shown in Figure 4:


    Figure 4. Modifying the server session timeout and the amount of time to wait for work to start

    Earlier, it was mentioned that a piece of work might get delayed if there are not enough threads in the WMQJCAResourceAdapter thread pool, which leads to the obvious question, "What should the size of this thread pool be?". One thread pool per application server is used by activation specifications to run server sessions. Each activation specification has an advanced property called Maximum server sessions, which defines the maximum number of concurrent server sessions that can be running at the same time. Since each server session is used to process messages, this property essentially says how many messages can be processed concurrently by message-driven beans using this activation specification. So in order to determine what the size of the WMQJCAResourceAdapter thread pool should be, you need to add up the values of the Maximum server sessions properties for each WebSphere MQ messaging provider activation specification on the application server. For example, suppose you have 25 activation specifications defined, each with the Maximum server sessions property set to 3. In this situation, there can be up to 75 server sessions running concurrently, each of them using a thread from the WMQJCAResourceAdapter thread pool. Therefore you should set the maximum size of this thread pool to 75. Figure 5 shows the WMQJCAResourceAdapter thread pool panel in the WebSphere Integrated Solutions Console, where you can change the size of this thread pool:


    Figure 5. Changing max number of threads available to all activation specifications defined in the application server.

    If you start seeing WorkRejected errors appearing in the application server SystemOut.log file, the first thing to check is that the WMQJCAResourceAdapter thread pool is large enough to handle all of the server sessions needed by your activation specifications. If the thread pool is the right size, then the errors are caused by the Work Manager being unable to start the work request within the specified time period. In this situation, you should either increase the value of the activation specification advanced property Start Timeout, or investigate reducing the load on your application server system.

    Using WebSphere MQ messaging provider normal mode

    As described above, there are three situations in which there might be a delay in between a message being detected and that message being processed by a message-driven bean:

    • If all server sessions associated with an activation specification are being used.
    • If all threads in the WMQJCAResourceAdapter thread pool are being used to process messages.
    • If there is a delay between work being scheduled and the Work Manager actually starting the work.

    If the activation specification is running in WebSphere MQ messaging provider normal mode, the queue manager marks messages before passing their details back to the activation specification. Marking the message means that no other activation specification (or WebSphere Application Server Listener Port), either running in the same application server or on a different application server, can see the message, which prevents another message-driven bean from getting the message before a server session has had time to process it.

    By default, messages are marked for 5 seconds. To change this time period, modify the WebSphere MQ queue manager property Message mark browse interval (MARKINT).

    After WebSphere MQ has passed details of a message to process to an activation specification, the 5 second timer starts. During these five seconds:

    1. The activation specification must get a server session from the server session pool.
    2. The server session must be loaded up with details of the message to process.
    3. The work must be scheduled.
    4. The Work Manager must start the work request.

    If there is a delay in getting a server session or a thread from the WMQJCAResourceAdapter thread pool, or if the system is busy and it takes a long time for the Work Manager to schedule the work, then the time between WebSphere MQ passing details of the message and it actually being consumed might be longer than 5 seconds. What happens in this situation?

    Well, if the message has been on the queue for longer than 5 seconds, the queue manager will unmark it, and another activation specification or listener port is then free to come along and get the message. If this happens, then when the server session that has previously been given details of this message tries to get it, it will find that the message is no longer on the destination, and write the following message to the application server SystemOut.log:

    CWSJY0003W: JMSCC0108: WebSphere classes for JMS attempted to get 
    a message for delivery to an message listener that had previously been 
    marked using browse-with-mark, but the message was not there.
    

    Should you see this message, you have three options:

    • Increase the value of the WebSphere MQ queue manager property Message mark browse interval (MARKINT), to give the activation specification more time to get the message. If you have multiple applications monitoring the same destination and want the messages to be processed quickly, you should think hard about adopting this approach, as increasing the amount of time the message is marked for will prevent any other applications from getting it.
    • Tune the application server so that it does not block either waiting for a server session or waiting for a thread from the WMQJCAResourceAdapter thread pool. To do this, increase the size of both the server session pool and the thread pool. This change will mean that messages can be processed within the default message browse mark interval, although more resources will be used within the application server as it will be able to process more messages concurrently.
    • Do nothing. Not recommended, because it means that the activation specification will waste time and resources trying to get messages that have already been picked up and processed by another application!

    Conclusion

    This article described the mechanisms that activation specifications use to get messages from WebSphere MQ queue managers, including how activation specifications create a connection to a queue manager and the mechanisms they use to monitor JMS destinations looking for suitable messages to process. The article also described how the application server schedules the processing of messages, once a suitable message has been found.

    [Edited By Moderator]

    0 (0 Ratings)
    [ 1631 views ] Leave a Comment

    IBM WebSphere MQ V7.5 delivers new features and integrates managed file transfer - Middleware News

    Thursday, May 17, 2012, 10:21 AM
    Categories: WebSphere MQ
    Posted By: Karthick

    WebSphere® MQ V7.5 for Multiplatforms provides additional enhancements to IBM® Universal Messaging to deliver a single, integrated offering for all core messaging functions. Customers gain access to previously separately installable capabilities, enabling more complete solutions for data and message movement along with reduced complexity.

    Enhancements include:



    Overview

    WebSphere MQ V7.5 delivers a single Universal Messaging solution. It enables the simple, rapid, reliable, and secure transport of data and messages between applications, systems, and services.

    WebSphere MQ is the market-leading, message-oriented middleware product that delivers a reliable, proven universal messaging backbone for almost 10,000 organizations of different sizes, spanning many industries around the world.

    This new release builds on the added capabilities and new functions that were delivered in WebSphere MQ V7.1, which was announced in October, 2011. It also builds on the previous announcements for WebSphere MQ File Transfer Edition V7.0.4, in April, 2011, and WebSphere MQ Advanced Message Security V7.0.1, in October, 2011.

    Note: WebSphere MQ for z/OS®, V7.1 is not updated in this release of WebSphere MQ V7.5 for Multiplatforms.

    You can obtain the new enhanced functions offered in WebSphere MQ V7.5 by migrating directly to V7.5 from WebSphere MQ V6.0, V7.0.1, or V.7.1 -- without migrating to an interim version or release.

    A key new feature of WebSphere MQ V7.5 is the consolidation of multiple previously separate product capabilities into a single integrated offering. WebSphere MQ File Transfer Edition and WebSphere MQ Advanced Message Security, both previously announced separate products, are now available as integrated capabilities for optional installation as Managed File Transfer and Advanced Message Security components within the WebSphere MQ product. They are subject to appropriate licensing entitlement.

    WebSphere MQ V7.1 introduced a capability to support install of different versions of WebSphere MQ in different locations on your system. WebSphere MQ V7.5 extends this to enable additional capabilities for Advanced Message Security and Managed File Transfer to be optionally installed as part of the WebSphere MQ server install.

    WebSphere MQ V7.5 queue managers gain access to these additional capabilities without requiring additional access to code, or separate product installs. All tooling necessary to use these functions is included in the MQ Explorer tooling or command line tools for scripted configuration as standard for all customers, including those on z/OS.

    Changes made to the licensing of the Extended Transactional Client and the WebSphere MQ Telemetry Client benefit all customers in providing increased entitlement. This applies to customers of WebSphere MQ V7.5 as well as WebSphere MQ V7.0.1 and WebSphere MQ V7.1.

    For ordering, contact Your IBM representative or an IBM Business Partner. For more information contact the Americas Call Centers at 800-IBM-CALL (426-2255). Reference: YE001


    Description
     

    WebSphere MQ delivers a single integrated Universal Messaging solution. This V7.5 release delivers new features and also enhances the total capabilities available through integrating managed file transfer functions and advanced message security capabilities that were previously available and installable as separate offerings.

    Integrated managed file transfer

    WebSphere MQ File Transfer Edition has been available as a separate product offering for a number of years, providing the ability for customers to move their business data stored in files over the WebSphere MQ infrastructure, improving the reliability, security, and management of their file transfers. WebSphere MQ V7.5 extends this capability from being a separate offering, to being an integrated optional feature of the WebSphere MQ server component as the WebSphere MQ Managed File Transfer Service. Now all WebSphere MQ servers can install, subject to entitlement, this server-based capability. Additional separately installable endpoints, WebSphere MQ Managed File Transfer Agents, are included in the package. These are entitled separately to allow customers to extend the managed file transfer infrastructure to any point in their enterprise connection to the WebSphere MQ server deployments.

    Integrated advanced message security

    WebSphere MQ Advanced Message Security, also available for a number of years, allows customers to protect the security of their messages from application to application, without the need to change the application code itself. With WebSphere MQ V7.5, this capability is included as a part of the install, making it simpler for customers to see the function, and to have it installed should they wish to buy license entitlement to use it.

    Improved application isolation

    WebSphere MQ V7.5 includes improved ability to scale for differing workload environments by the ability to configure multiple transmission queues in a WebSphere MQ clustered environment. This enables applications with different workloads and performance requirements to operate at their own rate without impacting other applications.

    Enhancements for the managed file transfer capabilities

    In addition to the tight integration, as a part of WebSphere MQ V7.5, which enhances the runtime control, the managed file transfer capabilities are also enhanced. There are additional choices for storing file transfer audit information with the addition of the file system as an option. There is also greater customization for the content and format, as well as more options for logging.

    Enhancements for WebSphere MQ Security

    The addition of Managed File Transfer capabilities as well as WebSphere MQ Advanced Message Security into WebSphere MQ V7.5 enables some improvements to the security possible within WebSphere MQ.

    With WebSphere MQ V7.5 the Advanced Message Security feature built into all MQ clients, end-to-end encryption is allowed by updates to WebSphere MQ objects for customers who are licensed to use that function. There is also further support for protecting sensitive data such as passwords used in configuring managed file transfers.

    Wider access to the Extended Transactional Client for all customers

    The Extended Transactional Client enables customers to configure their WebSphere MQ client to participate in a transactional unit of work when exchanging messages to an MQ server. Use of this client without charge was previously restricted to customers using WebSphere Application Server, WebSphere Enterprise Service Bus, or WebSphere Process Server as the Transaction Manager. With the announcement of WebSphere MQ V7.5, the Extended Transactional Client is available for use in all client deployments without additional entitlement. This includes all supported versions of WebSphere MQ client connecting to any supported version of WebSphere MQ queue manager.

    With the availability of WebSphere MQ V7.5 the capability previously delivered within the Extended Transactional Client is incorporated into the standard WebSphere MQ client. Customers using WebSphere MQ V7.0.1 and WebSphere MQ V7.1 gain the benefit of use of the Extended Transactional Client without charge from the date of this announcement. IBM is making available refreshed code including updated License Information. Customers can realize this benefit through the download and acceptance of this new License Information.

    Using WebSphere MQ Telemetry Standard Client

    WebSphere MQ Telemetry was included as part of the WebSphere MQ V7.1 offering, providing wider access to this capability for customers who wanted to deploy the WebSphere MQ Telemetry clients on suitable endpoints and connect them to their WebSphere MQ servers.

    Connecting these clients to WebSphere MQ servers required purchasing entitlements based on the number of Telemetry clients connecting to a WebSphere MQ Queue Manager at any one time. With the announcement of WebSphere MQ V7.5, use of the WebSphere MQ Telemetry Client requires purchasing an entitlement for WebSphere MQ Telemetry Clients for each WebSphere MQ Server installed that will have WebSphere MQ Telemetry clients connected to it, with no limit to the number of clients connected. This change in the license entitlement for WebSphere MQ Telemetry Clients applies to not just WebSphere MQ V7.5. It also benefits customers using WebSphere MQ Telemetry Clients with WebSphere MQ V7.0.1 and WebSphere MQ V7.1 from the date of this announcement. IBM is making available refreshed code including updated License Information and customers can realize this benefit through the download and acceptance of this new License Information.

    The WebSphere MQ Telemetry Advanced Client entitlements are still based on the number of clients connected at any one time.

    Enhancements for the use of WebSphere MQ as a trial

    Customers wanting to make a rapid start connecting applications with WebSphere MQ can take advantage of the availability of WebSphere MQ as a free download in a trial version. With WebSphere MQ V7.1 this feature was enhanced to enable trial versions of WebSphere MQ to be upgraded to a full production license. With the integration of additional entitled capabilities in WebSphere MQ V7.5, a trial download is still available. However, where entitlement was not purchased at the end of the trial for capabilities that were installed, then those capabilities without entitlement must be removed from the system.

    Accessibility by people with disabilities

    WebSphere MQ is capable as of June 15, 2012, when used in accordance with associated IBM documentation, of satisfying the applicable requirements of Section 508 of the Rehabilitation Act, provided that any assistive technology used with the product properly interoperates with it.

     
    0 (0 Ratings)
    [ 995 views ] Leave a Comment

    Performance: Getting the Most Out of IBM WebSphere MQ - Middleware News

    Wednesday, May 16, 2012, 11:11 AM
    Categories: WebSphere MQ
    Posted By: Karthick

    Getting the most out of WebSphere MQ first requires you to define performance. This should be followed up with a look at several factors that affect WebSphere MQ performance, and techniques that can be used to improve performance.

    What is Performance

    The concept of performance has different aspects. When addressing the issue of performance, your first consideration should be to identify the aspect you plan to address.
    People associate performance with:

    • The measurement of response time. Thus, better performance is defined as the completion of a task in less time (quicker response).


    • Moving the work through the system with less impact on the system and other applications.


    • Providing the most throughput at peak times.


    • Availability. The application has to be available when required.
    Based on your objectives, you may address performance similarly, but the trade-offs you choose may vary.

    WebSphere MQ applications

    Different types of WebSphere MQ applications have different performance characteristics. Several types are provided below.
    Asynchronous send
    The asynchronous send application sends messages based on some external activity. Examples might include a stock ticker or an application that reports scores for a sports event.
    This application is primarily concerned with throughput, in that it needs to keep up with the rate that events occur. Whether the message takes seconds or days to reach its destination, once it is sent, it does not affect the application.
    Synchronous send and receive
    Another common type of WebSphere MQ application is the synchronous application. Technically, this application is not synchronous, but rather it is an asynchronous one that expects a timely response to the sent message. For this application, the key concern is the response time for the reply message(s). If the responding application is remote (on a network), this time includes WebSphere MQ processing on multiple hosts, the processing by the remote application and the network transmission time for both messages.
    It is possible given the design of WebSphere MQ that the response may not be timely and must be dealt with by the application design. For example, if the application does an infinite wait for the message to arrive, this will consume system resources and could affect other applications.
    Server
    The server application is complementary to the previous two examples. It processes WebSphere MQ messages; performs local processing, such as accessing a database; and may send a response. Multiple servers may be used to share a portion of the workload.
    WebSphere MQ client
    The WebSphere MQ client application may be an implementation of any of the previous applications, but introduces a key response-driven component. As there is no local queue manager, all requests must pass over the network to the associated server queue manager. The number of requests, the speed at which the request and response can be transmitted, and the additional processing time on the server are all components of the application's performance.

    Factors that affect WebSphere MQ performance - an overview

    There are many different factors that address performance. Given the diversity of WebSphere MQ environments, some recommendations may or may not be applicable. For each, there is typically a trade-off in providing better performance to the WebSphere MQ application, such as degrading another application. It is important that the cost and benefit are understood before making changes.
    The usual suspects
    The key elements of response time have not changed in more than 20 years.

    • The processor time to service the application plus the overhead of the operating environment (in this case, WebSphere MQ and the operating system)


    • The time spent waiting for I/O operations (all computers wait at the same speed)


    • The time spent transmitting requests over a network


    • Any contention for resources required by the application
    Each of these key components will be addressed in the following sections.
    Adding system resources
    The most common approach to improving performance is simply to add additional resources. To accomplish this, you could try moving the queue manager to a larger server or adding additional memory. With today's price-to-performance ratios, this can provide significant improvements at little cost.

    Performance Factors and Techniques

    CPU factors

    The main component of CPU consumption for a WebSphere MQ application is the type and number of MQI calls issued.
    Calls in order of CPU consumption:

    • MQCONN - connects to the queue manager, creates required task structures and control blocks


    • MQOPEN - opens a specific queue for processing, may lock required resources and acquires control blocks


    • MQCLOSE - closes the queue, commits resources, frees locks and releases control blocks


    • MQPUT - puts a message to a queue (recovery processing may be required)


    • MQGET - gets a message from a queue (recovery processing may be required)
    On S390, most CPU is charged to the calling application. On distributed systems, an agent process is used to communicate with WebSphere MQ, and this process will consume most WebSphere MQ-related CPU.
    Avoid unnecessary calls
    The best and most obvious way to avoid CPU consumption is to avoid unnecessary MQI calls. For example, consider the server application discussed previously. The application could be designed to trigger the server's start when a message arrives, connect to the queue manager, open the queue, retrieve the message and process the response (opening a second queue), close all queues and disconnect from the queue manager. The process would repeat for the next message, and so on. This may be a good solution for a low arrival rate. However, for higher message arrival rates, there are two alternatives.
    First, rather than closing all queues and disconnecting1, the application could try to do an additional get with wait2 from the queue. If another message is already available, it could process this message and avoid additional connect and open calls3. This process could be repeated until no unprocessed messages remain, and only then would the server terminate. If the message arrival rate is high enough, rather than using triggering, the application could be permanently active, simply looping on a get with wait call. Note that if the arrival rate is insufficient, the above solutions could be unnecessary processing.
    Reduce message size and/or compress messages
    Message size is a key component in message processing. While application developers can be coerced into reducing message size, there is no guarantee that they will do so. Traditionally, software solutions to compress messages have had a greater success rate than those that relied on application methodology. As seen in Figure 1, which demonstrates the use of compression software, message size can have a significant impact on CPU time. This is primarily due to data movement within the queue manager. Data must be moved out of the application and into WebSphere MQ buffers. It must be logged if persistent, and may have to be written to and read from physical DASD.
    Figure 1—CPU Consumption
    Directly related to the reduced CPU, but also due to I/O and network transmission time savings achieved, the elapsed time of the compressed data is significantly lower than that of the native messages.
    To achieve these savings however, it should be noted that messages must be compressed prior to their placement on the queue.
    Reduced number of messages
    Is one big message better than several small ones? Opinions vary.
    Larger messages are subject to additional processing overhead, whereas each small message incurs a base amount of processing. WebSphere MQ now supports messages up to 100MB, so it is possible to logically join multiple records (taking care not to go overboard). Define messages that make sense from an application point of view, and don't overanalyze message design. If the number of messages is low, the difference in processing for either method will be small. If a large number of messages are being written, combining the messages may result in a significant reduction in processing overhead.
    Use intermediate commits for large numbers of messages
    There are several reasons to periodically commit messages. First, the processing required is not linear to the number of messages. The impact of the final commit increases as the number of messages in the unit of work increases. Second, periodic commits spread the total time to process over a longer period (less impact on other applications). Third, messages are not visible to other applications until they have been committed, thus the messages will appear all at once to the server application. The processing application may be overwhelmed. Of course, the commits must be reflected in completed units of work.
    Queue use
    Is it better to have a single queue shared by multiple application instances or individual queues? This is an area of debate, but it typically does not make sense to share queues across different applications. However, it may make sense to share queues within an application domain. For example, the Command MQ for S/390 product from BMC Software supports multiple users connected to a single queue manager. It could have been designed with a unique queue per user, but instead it implements a single queue shared by all users based on correlation ID (CorrelId), resulting in fewer queues to manage.
    WebSphere MQ on distributed platforms uses an indexed technique to make this efficient. On S/390 with V1.2 and later, the queue can be defined as indexed. This builds an in-storage index. The index can be based on message ID (MsgId) or CorrelId, but not both. This is not typically a problem, as applications use one or the other. However, if the queue is a priority-based queue, additional processing is required for each message with the same index.
    If you have applications displaying this behavior, it is important that you define the associated queue as indexed. Consider a queue with 1,000 messages for application A, followed by 50 messages for application B. To read the 50 messages, application B would actually read the 1,000 messages for application A before hitting any of its own messages. Depending on application design, this could result in a total reference of 50,050 messages to process all 50 messages.
    Defining a queue as indexed adds a minimal amount of additional processing during put processing, but can be noticeable during queue manager restart for large queues.
    Additionally, if all access to the queue is by MsgId or CorrelId and message expiry is used, it is possible to fill a queue with expired messages. WebSphere MQ does not remove messages until the expired message's get with update is performed.
    Trusted applications
    For distributed queue managers, another CPU consumer is process switching. Process switching prevents the corruption of WebSphere MQ due to application program errors.
    The queue manager is isolated from the application program through the use of an agent process that executes within the queue manager domain. For each WebSphere MQ call, an IPC is used to switch from the application to the agent. When defined as trusted, the application, the agent and the queue manager are within a common domain. This eliminates the overhead, but leaves the queue manager open to corruption by the application. Thus, it is intended only for truly trusted applications.
    Trusted applications are primarily used for the WebSphere MQ channel agents. While from a WebSphere MQ perspective these are application programs, from a customer point of view they are part of WebSphere MQ. These should be configured as trusted, reducing overhead for the channel processing. Channel exits will execute within the trusted environment, should be evaluated, and must conform to trusted application restrictions. Note that an application must be designed to use trusted binding. For example, it must use an MQCONNX call instead of the standard MQCONN call.

    I/O factors

    I/O can be a major component of a WebSphere MQ application, particularly if logging is the primary factor. In order to provide guaranteed once-and-once-only delivery, WebSphere MQ must log every processed message. Additionally, WebSphere MQ must ensure that the log has been committed prior to the work unit's completion.
    Queue I/O is typically performed independent from application response time, but could affect device use. When processed within a resource manager, I/O to the queue is not performed unless buffer space is exhausted. Therefore, it is possible for a message to be sent to a queue and read by the processing application without ever being written to the physical queue storage.
    Use nonpersistent messages when appropriate
    Because logging is only performed for persistent messages, using nonpersistent messages eliminates logging activity. Nonpersistent messages are not guaranteed from a WebSphere MQ perspective. That is, they may never be delivered. Most notably, nonpersistent messages are not maintained across a restart of the queue manager. Some cases of non-persistent messages make sense. For example, consider an application that sends the current temperature. If a single reporting instance is lost, correction will occur with the next temperature report. However, stock trade messages cannot be lost.
    Reduce message size and/or compress messages
    0 (0 Ratings)
    [ 833 views ] Leave a Comment

    How SSL works tutorial - with HTTPS example - Middleware News

    Sunday, May 6, 2012, 10:44 AM
    Categories: Security
    Posted By: Karthick

    How SSL works tutorial - with HTTPS example - Middleware News

    3.2 (1 Ratings)
    [ 1334 views ] Leave a Comment

    Secure Sockets Layer (SSL) return codes / Secure Sockets Layer / SSL - Middleware News

    Sunday, May 6, 2012, 10:42 AM
    Categories: Security
    Posted By: Karthick

    Secure Sockets Layer (SSL) return codes
    =============================

    The table in this appendix documents the return codes, in decimal form, from the Secure Sockets Layer (SSL) that can be returned in messages from the distributed queuing component.

    If the return code is not listed, or if you want more information, refer to the IBM Global Security Kit return codes here:

    publib.boulder.ibm.com/infocenter/tivihe...

    Table 1. SSL return codesReturn code (decimal) Explanation

    1 Handle is not valid.
    3 An internal error has occured.
    4 Insufficient storage is available
    5 Handle is in the incorrect state.
    6 Key label is not found.
    7 No certificates available.
    8 Certificate validation error.
    9 Cryptographic processing error.
    10 ASN processing error.
    11 LDAP processing error.
    12 An unexpected error has occurred.
    102 Error detected while reading key database or SAF key ring.
    103 Incorrect key database record format.
    106 Incorrect key database password.
    109 No certification authority certificates.
    201 No key database password supplied.
    202 Error detected while opening the key database.
    203 Unable to generate temporary key pair
    204 Key database password is expired.
    302 Connection is active.
    401 Certificate is expired or is not valid yet.
    402 No SSL cipher specifications.
    403 No certificate received from partner.
    405 Certificate format is not supported.
    406 Error while reading or writing data.
    407 Key label does not exist.
    408 Key database password is not correct.
    410 SSL message format is incorrect.
    411 Message authentication code is incorrect.
    412 SSL protocol or certificate type is not supported.
    413 Certificate signature is incorrect.
    414 Certificate is not valid.
    415 SSL protocol violation.
    416 Permission denied.
    417 Self-signed certificate cannot be validated.
    420 Socket closed by remote partner.
    421 SSL V2 cipher is not valid.
    422 SSL V3 cipher is not valid.
    427 LDAP is not available.
    428 Key entry does not contain a private key.
    429 SSL V2 header is not valid.
    431 Certificate is revoked.
    432 Session renegotiation is not allowed.
    433 Key exceeds allowable export size.
    434 Certificate key is not compatible with cipher suite.
    435 Certification authority is unknown.
    436 Certificate revocation list cannot be processed.
    437 Connection closed.
    438 Internal error reported by remote partner.
    439 Unknown alert received from remote partner.
    501 Buffer size is not valid.
    502 Socket request would block.
    503 Socket read request would block.
    504 Socket write request would block.
    505 Record overflow.
    601 Protocol is not SSL V3 or TLS V1.
    602 Function identifier is not valid.
    701 Attribute identifier is not valid.
    702 The attribute has a negative length, which is invalid.
    703 The enumeration value is invalid for the specified enumeration type.
    704 Invalid parameter list for replacing the SID cache routines.
    705 The value is not a valid number.
    706 Conflicting parameters were set for additional certificate validation
    707 The AES cryptographic algorithm is not supported.
    708 The PEERID does not have the correct length.
    1501 GSK_SC_OK
    1502 GSK_SC_CANCEL
    1601 The trace started successfully.
    1602 The trace stopped successfully.
    1603 No trace file was previously started so it cannot be stopped.
    1604 Trace file already started so it cannot be started again.
    1605 Trace file cannot be opened. The first parameter of gsk_start_trace() must be a valid full pathfilename.
    0 (0 Ratings)
    [ 822 views ] Leave a Comment

    IBM Websphere MQ - Channel attributes in alphabetical order - Middlewar News

    Sunday, May 6, 2012, 10:37 AM
    Categories: WebSphere MQ
    Posted By: Karthick

    IBM Websphere MQ - Channel attributes in alphabetical order - Middlewar News



    WebSphere MQ for some platforms may not implement all the attributes shown in the list. Exceptions and platform differences are mentioned in the individual attribute descriptions, where relevant.

    The keyword that you can specify in MQSC is shown in brackets for each attribute. (Attributes that apply only to WebSphere MQ for z/OS with CICS do not have MQSC keywords.)

    The attributes are arranged in alphabetical order, as follows:

    * Auto start (AUTOSTART)
    * Alter date (ALTDATE)
    * Alter time (ALTTIME)
    * Batch Heartbeat Interval (BATCHHB)
    * Batch interval (BATCHINT)
    * Batch size (BATCHSZ)
    * Channel name (CHANNEL)
    * Channel type (CHLTYPE)
    * CICS profile name
    * Cluster (CLUSTER)
    * Cluster namelist (CLUSNL)
    * Connection name (CONNAME)
    * Convert message (CONVERT)
    * Description (DESCR)
    * Disconnect interval (DISCINT)
    * Heartbeat interval (HBINT)
    * Local Address (LOCLADDR)
    * Long retry count (LONGRTY)
    * Long retry interval (LONGTMR)
    * LU 6.2 mode name (MODENAME)
    * LU 6.2 transaction program name (TPNAME)
    * Maximum message length (MAXMSGL)
    * Maximum transmission size
    * Message channel agent name (MCANAME)
    * Message channel agent type (MCATYPE)
    * Message channel agent user identifier (MCAUSER)
    * Message exit name (MSGEXIT)
    * Message exit user data (MSGDATA)
    * Message-retry exit name (MREXIT)
    * Message-retry exit user data (MRDATA)
    * Message retry count (MRRTY)
    * Message retry interval (MRTMR)
    * Nonpersistent message speed (NPMSPEED)
    * Password (PASSWORD)
    * PUT authority (PUTAUT)
    * Queue manager name (QMNAME)
    * Receive exit name (RCVEXIT)
    * Receive exit user data (RCVDATA)
    * Security exit name (SCYEXIT)
    * Security exit user data (SCYDATA)
    * Send exit name (SENDEXIT)
    * Send exit user data (SENDDATA)
    * Sequence number wrap (SEQWRAP)
    * Sequential delivery
    * Short retry count (SHORTRTY)
    * Short retry interval (SHORTTMR)
    * SSL Cipher Specification (SSLCIPH)
    * SSL Client Authentication (SSLCAUTH)
    * SSL Peer (SSLPEER)
    * Target system identifier
    * Transmission queue name (XMITQ)
    * Transport type (TRPTYPE)
    * User ID (USERID)

    Alter date (ALTDATE)

    This is the date on which the definition was last altered, in the form yyyy-mm-dd.

    This parameter is supported on AIX, HP-UX, Linux, OS/2 Warp, z/OS, iSeries, Solaris, and Windows systems only.

    Alter time (ALTTIME)

    This is the time at which the definition was last altered, in the form hh:mm:ss.

    This parameter is supported on AIX, HP-UX, Linux, OS/2 Warp, z/OS, iSeries, Solaris, and Windows systems only.

    Auto start (AUTOSTART)

    In MQSeries for Compaq NonStop Kernel there is no SNA listener process. Each channel initiated from a remote system must have its own, unique TP name on which it can listen. Such channels must be defined to MQSC with the attribute AUTOSTART(ENABLED) to ensure that there is an LU 6.2 responder process listening on this TP name whenever the queue manager is started.

    SNA channels defined AUTOSTART(DISABLED) do not listen for incoming SNA requests. LU 6.2 responder processes are not started for such channels.

    Batch Heartbeat Interval (BATCHHB)

    The batch heartbeat interval allows a sending channel to verify that the receiving channel is still active just before committing a batch of messages, so that if the receiving channel is not active, the batch can be backed out rather than becoming in-doubt, as would otherwise be the case. By backing out the batch, the messages remain available for processing so they could, for example, be redirected to another channel.

    If the sending channel has had a communication from the receiving channel within the batch heartbeat interval, the receiving channel is assumed to be still active, otherwise a 'heartbeat' is sent to the receiving channel to check.

    The value must be in the range zero through 999 999. A value of zero indicates that batch heartbeating is not used.

    This parameter is valid for the following channel types:

    * Sender
    * Server
    * Cluster sender
    * Cluster receiver

    Batch interval (BATCHINT)

    WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for OS/2 Warp, and WebSphere MQ for z/OS without CICS, you can specify a period of time, in milliseconds, during which the channel will keep a batch open even if there are no messages on the transmission queue. You can specify any number of milliseconds, from zero through 999 999 999. The default value is zero.

    If you do not specify a batch interval, the batch closes when the number of messages specified in BATCHSZ has been sent or when the transmission queue becomes empty. On lightly loaded channels, where the transmission queue frequently becomes empty the effective batch size may be much smaller than BATCHSZ.

    You can use the BATCHINT attribute to make your channels more efficient by reducing the number of short batches. Be aware, however, that you may slow down the response time, because batches will last longer and messages will remain uncommitted for longer.

    If you specify a BATCHINT, batches close only when one of the following conditions is met:

    * The number of messages specified in BATCHSZ have been sent.
    * There are no more messages on the transmission queue and a time interval of BATCHINT has elapsed while waiting for messages (since the first message of the batch was retrieved).

    Note:
    BATCHINT specifies the total amount of time that is spent waiting for messages. It does not include the time spent retrieving messages that are already available on the transmission queue, or the time spent transferring messages.

    This attribute applies only to sender, cluster-sender, server, and cluster-receiver channels.

    Batch size (BATCHSZ)

    The batch size is the maximum number of messages to be sent before a syncpoint is taken. The batch size does not affect the way the channel transfers messages; messages are always transferred individually, but are committed or backed out as a batch.

    To improve performance, you can set a batch size to define the maximum number of messages to be transferred between two syncpoints. The batch size to be used is negotiated when a channel starts up, and the lower of the two channel definitions is taken. On some implementations, the batch size is calculated from the lowest of the two channel definitions and the two queue manager MAXUMSGS values. The actual size of a batch can be less than this; for example, a batch completes when there are no messages left on the transmission queue or the batch interval expires.

    A large value for the batch size increases throughput, but recovery times are increased because there are more messages to back out and re-send. The default BATCHSZ is 50, and you are advised to try that value first. You might choose a lower value for BATCHSZ if your communications are unreliable, making the need to recover more likely.

    Syncpoint procedure needs a unique logical unit of work identifier to be exchanged across the link every time a syncpoint is taken, to coordinate batch commit procedures.

    If the synchronized batch commit procedure is interrupted, an in-doubt situation may arise. In-doubt situations are resolved automatically when a message channel starts up. If this resolution is not successful, manual intervention may be necessary, making use of the RESOLVE command.

    Some considerations when choosing the number for batch size:

    * If the number is too large, the amount of queue space taken up on both ends of the link becomes excessive. Messages take up queue space when they are not committed, and cannot be removed from queues until they are committed.
    * If there is likely to be a steady flow of messages, you can improve the performance of a channel by increasing the batch size. However, this has the negative effect of increasing restart times, and very large batches may also affect performance.
    * If message flow characteristics indicate that messages arrive intermittently, a batch size of 1 with a relatively large disconnect time interval may provide a better performance.
    * The number may be in the range 1 through 9999. However, for data integrity reasons, channels connecting to any of the current platforms, as described in this book, should specify a batch size greater than 1. (A value of 1 is for use with Version 1 products, apart from MQSeries for MVS/ESA.)

    For z/OS using CICS it must also be at least 3 less than the value set by the ALTER QMGR MAXUMSGS command.
    * Even though nonpersistent messages on a fast channel do not wait for a syncpoint, they do contribute to the batch-size count.

    Channel name (CHANNEL)

    Specifies the name of the channel definition. The name can contain up to 20 characters, although as both ends of a message channel must have the same name, and other implementations may have restrictions on the size, the actual number of characters may have to be smaller.

    Where possible, channel names should be unique to one channel between any two queue managers in a network of interconnected queue managers.

    The name must contain characters from the following list:
    Alphabetic (A-Z, a-z; note that uppercase and lowercase are significant)
    Numerics (0-9)
    Period (.)
    Forward slash (/)
    Underscore (_)
    Percentage sign (%)

    Notes:

    1. Embedded blanks are not allowed, and leading blanks are ignored.

    2. On systems using EBCDIC Katakana, you cannot use lowercase characters.

    Channel type (CHLTYPE)

    Specifies the type of the channel being defined. The possible channel types are:

    Message channel types:

    * Sender
    * Server (not MQSeries for VSE/ESA)
    * Cluster-sender (WebSphere MQ for z/OS without CICS, WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp only)
    * Receiver
    * Requester (not MQSeries for VSE/ESA)
    * Cluster-receiver (WebSphere MQ for z/OS without CICS, WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, only)

    MQI channel types:

    * Client-connection (MQSeries for OS/2 Warp, VSE/ESA, DOS, Windows 3.1, Windows 95, and Windows 98 only, and WebSphere MQ for Windows systems, and UNIX systems only)

    Note:
    Client-connection channels can also be defined on z/OS for use on other platforms.

    * Server-connection (not WebSphere MQ for z/OS using CICS)

    The two ends of a channel must have the same name and have compatible types:

    * Sender with receiver
    * Requester with server
    * Requester with sender (for Call_back)
    * Server with receiver (server is used as a sender)
    * Client-connection with server-connection
    * Cluster-sender with cluster-receiver

    CICS profile name

    This is for z/OS using CICS only, to give extra definition for the session characteristics of the connection when CICS performs a communication session allocation, for example to select a particular COS.

    The name must be known to CICS and be one to eight alphanumeric characters long.

    Cluster (CLUSTER)

    The name of the cluster to which the channel belongs. The maximum length is 48 characters conforming to the rules for naming WebSphere MQ objects.

    This parameter is valid only for cluster-sender and cluster-receiver channels. Up to one of the resultant values of CLUSTER or CLUSNL can be nonblank. If one of the values is nonblank, the other must be blank.

    This parameter is supported on AIX, HP-UX, Linux, OS/2 Warp, z/OS without CICS, iSeries, Solaris, and Windows systems only.

    Cluster namelist (CLUSNL)

    The name of the namelist that specifies a list of clusters to which the channel belongs.

    This parameter is valid only for cluster-sender and cluster-receiver channels. Up to one of the resultant values of CLUSTER or CLUSNL can be nonblank. If one of the values is nonblank, the other must be blank.

    This parameter is supported on AIX, HP-UX, Linux, OS/2 Warp, z/OS without CICS, iSeries, Solaris, and Windows systems only.

    Connection name (CONNAME)

    This is the communications connection identifier. It specifies the particular communications link to be used by this channel.

    This attribute is required for sender channels, cluster-sender channels, cluster-receiver channels, requester channels, and client-connection channels. It does not apply to receiver or server-connection channel types.

    It is optional for server channels, except on z/OS using CICS where it is required in the channel definition, but is ignored unless the server is initiating the conversation.

    For z/OS using CICS this attribute names the CICS communication connection identifier for the session to be used for this channel. The name is one to four alphanumeric characters long.

    Otherwise, the name is up to 48 characters for z/OS, 264 characters for other platforms, and:

    If the transport type is TCP
    This is either the hostname or the network address of the remote machine (or the local machine for cluster-receiver channels). For example, (MACH1.ABC.COM) or (19.22.11.162). It may include the port number, for example (MACHINE(123)). It can include the IP_name of a z/OS dynamic DNS group or a network dispatcher input port.

    If the transport type is UDP
    For WebSphere MQ for AIX only, UDP is an alternative to TCP. As with TCP/IP, it is either the hostname or the network address of the remote machine.

    If the transport type is LU 6.2
    For MQSeries for OS/2, and WebSphere MQ for iSeries, Windows systems, and UNIX systems, give the fully-qualified name of the partner LU if the TPNAME and MODENAME are specified. For other versions or if the TPNAME and MODENAME are blank, give the CPI-C side information object name as described in the section in this book about setting up communication for your platform.

    On z/OS there are two forms in which to specify the value:

    * Logical unit name

    The logical unit information for the queue manager, comprising the logical unit name, TP name, and optional mode name. This can be specified in one of 3 forms:

    luname, for example IGY12355

    luname/TPname, for example IGY12345/APING

    luname/TPname/modename, for example IGY12345/APINGD/#INTER

    For the first form, the TP name and mode name must be specified for the TPNAME and MODENAME attributes ; otherwise these attributes must be blank.

    Note:
    For client-connection channels, only the first form is allowed.

    * Symbolic name

    The symbolic destination name for the logical unit information for the queue manager, as defined in the side information data set. The TPNAME and MODENAME attributes must be blank.

    Note:
    For cluster-receiver channels, the side information is on the other queue managers in the cluster. Alternatively, in this case it can be a name that a channel auto-definition exit can resolve into the appropriate logical unit information for the local queue manager.

    The specified or implied LU name can be that of a VTAM(R) generic resources group.

    For Compaq OpenVMS Alpha, specify the Gateway Node name, the Access Name to the channel program, and the TPNAME used to invoke the remote program. For example: CONNAME('SNAGWY.VMSREQUESTER(HOSTVR)').

    For Compaq NonStop Kernel, the value depends on whether SNAX or ICE is used; see Chapter 20, Setting up communication in Compaq NonStop Kernel.

    If the transmission protocol is NetBIOS
    This is the NetBIOS name defined on the remote machine.

    If the transmission protocol is SPX
    This is an SPX-style address consisting of a 4-byte network address, a 6-byte node address and a 2-byte socket number. Enter these in hexadecimal, with the network and node addresses separated by a fullstop and the socket number in brackets. For example:

    CONNAME('0a0b0c0d.804abcde23a1(5e86)')

    If the socket number is omitted, the default WebSphere MQ SPX socket number is used. The default is X'5E86'.

    Note:
    The definition of transmission protocol is contained in Transport type (TRPTYPE).

    Convert message (CONVERT)

    Application message data is usually converted by the receiving application. However, if the remote queue manager is on a platform that does not support data conversion, use this channel attribute to specify that the message should be converted into the format required by the receiving system before transmission.

    This attribute applies only to sender, cluster-sender, server, and cluster-receiver channels and does not apply to WebSphere MQ for z/OS with CICS.

    The possible values are 'yes' and 'no'. If you specify 'yes', the application data in the message is converted before sending if you have specified one of the built-in format names, or a data conversion exit is available for a user-defined format (See the WebSphere MQ Application Programming Guide). If you specify 'no', the application data in the message is not converted before sending.

    Description (DESCR)

    This contains up to 64 bytes of text that describes the channel definition.

    Note:
    The maximum number of characters is reduced if the system is using a double byte character set (DBCS).

    Use characters from the character set identified by the coded character set identifier (CCSID) for the queue manager to ensure that the text is translated correctly if it is sent to another queue manager.

    Disconnect interval (DISCINT)

    This is a time-out attribute, specified in seconds, for the server, cluster-sender, sender, and cluster-receiver channels. The interval is measured from the point at which a batch ends, that is when the batch size is reached or when the batch interval expires and the transmission queue becomes empty. If no messages arrive on the transmission queue during the specified time interval, the channel closes down. (The time is approximate.)

    The close-down exchange of control data between the two ends of the channel includes an indication of the reason for closing. This ensures that the corresponding end of the channel remains available to start up again.

    On all platforms except z/OS with CICS, you can specify any number of seconds from zero through 999 999 where a value of zero means no disconnect; wait indefinitely.

    In z/OS using CICS, you can specify any number of seconds from zero through 9999 where a value of zero means disconnect as soon as the transmission queue is empty.

    Note:
    Performance is affected by the value specified for the disconnect interval.

    A very low value (a few seconds) may cause excessive overhead in constantly starting up the channel. A very large value (more than an hour) could mean that system resources are unnecessarily held up. For WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, and for WebSphere MQ for z/OS without CICS, you can also specify a heartbeat interval, so that when there are no messages on the transmission queue, the sending MCA will send a heartbeat flow to the receiving MCA, thus giving the receiving MCA an opportunity to quiesce the channel without waiting for the disconnect interval to expire. For these two values to work together effectively, the heartbeat interval value must be significantly lower than the disconnect interval value.

    A value for the disconnect interval of a few minutes is a reasonable value to use. Change this value only if you understand the implications for performance, and you need a different value for the requirements of the traffic flowing down your channels.

    For more information, see Stopping and quiescing channels.

    Heartbeat interval (HBINT)

    This attribute applies to WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, and for WebSphere MQ for z/OS without CICS. You can specify the approximate time between heartbeat flows that are to be passed from a sending MCA when there are no messages on the transmission queue. Heartbeat flows unblock the receiving MCA, which is waiting for messages to arrive or for the disconnect interval to expire. When the receiving MCA is unblocked it can disconnect the channel without waiting for the disconnect interval to expire. Heartbeat flows also free any storage buffers that have been allocated for large messages and close any queues that have been left open at the receiving end of the channel.

    The value is in seconds and must be in the range 0 through 999 999. A value of zero means that no heartbeat flows are to be sent. The default value is 300. To be most useful, the value should be significantly less than the disconnect interval value.

    This attribute is valid for sender, cluster-sender, server, receiver, cluster-receiver, and requester channels. Other than on z/OS and iSeries, it also applies to server-connection and client-connection channels. On these channels, heartbeats flow when a server MCA has issued an MQGET command with the WAIT option on behalf of a client application.

    KeepAlive Interval (KAINT)

    The KeepAlive Interval parameter is used to specify a time-out value for a channel.

    The KeepAlive Interval parameter is a value passed to the communications stack specifying the KeepAlive timing for the channel. It allows you to specify a different keepalive value for each channel.

    The value indicates a time, in seconds, and must be in the range 0 to 99999. A KeepAlive value of 0 indicates that channel KeepAlive is not enabled for the channel. When the KeepAlive Interval is set to 0, keepalive still occurs if a value has been specified for TCP/IP keepalive. On z/OS, this occurs when the TCPKEEP=YES parameter is specified in CSQ6CHIP. On other platforms, it occurs when the KEEPALIVE=YES parameter is specified in the TCP stanza in the distributed queuing configuration file.



    This parameter is valid for all channel types. The value is ignored for all channels that have a TransportType (TRPTYPE) other than TCP or SPX

    KAINT is only available on WebSphere MQ for z/OS.

    Local Address (LOCLADDR)

    This parameter specifies the local communications address for the channel. When a LOCLADDR value is specified, a channel that is stopped and then restarted continues to use the TCP/IP address specified in LOCLADDR. In recovery scenarios, this could be useful when the channel is communicating through a firewall, because it removes problems caused by the channel restarting with a different IP address, specified by the TCP/IP stack to which it is connected.

    This parameter is valid for the following channel types:

    * Sender
    * Server
    * Requester
    * Client-connection
    * Cluster-receiver
    * Cluster-sender

    The value used is the optional IP address and optional port or port range to be used for outbound TCP/IP communications. The format is as follows:

    LOCLADDR([ip-addr][(low-port[,high-port])])

    where "ip-addr" is specified in dotted alphanumeric or decimal form, for example, (MACH1.ABC.COM) or (19.22.11.162), and "low-port" and "high-port" are port numbers enclosed in parentheses. When two port values are specified, the channel binds to the address specified, using an available port within the range covered by the two port values. All values are optional.

    The maximum length of the string is MQ_LOCAL_ADDRESS_LENGTH.

    Note:
    If the LOCLADDR port is in use, TCP/IP requires a time period to release the previously used port. If enough time is not left, and if only 1 LOCLADDR port is specified, the previously used port will not be available and so a random port will be chosen rather than the LOCLADDR port.

    Long retry count (LONGRTY)

    Specify the maximum number of times that the channel is to try allocating a session to its partner. If the initial allocation attempt fails, the short retry count number is decremented and the channel retries the remaining number of times. If it still fails, it retries a long retry count number of times with an interval of long retry interval between each try. If it is still unsuccessful, the channel closes down. The channel must subsequently be restarted with a command (it is not started automatically by the channel initiator).

    (Retry is not attempted if the cause of failure is such that a retry is not likely to be successful.)

    If the channel initiator or queue manager stops while the channel is retrying, the short retry count and long retry count are reset when the channel initiator or queue manager is restarted.

    The long retry count attribute is valid only for channel types of sender, cluster-sender, server, and cluster-receiver. It is also valid for requester channels on z/OS if you are using CICS. It may be set from zero through 999 999 999. On z/OS using CICS, it may be set from zero through 999, and the long and short retries have the same count.

    Note:
    For OS/2, iSeries, UNIX systems, and Windows systems, in order for retry to be attempted a channel initiator must be running. The channel initiator must be monitoring the initiation queue specified in the transmission queue that the channel is using.

    Long retry interval (LONGTMR)

    The approximate interval in seconds that the channel is to wait before retrying to establish connection, during the long retry mode.

    The interval between retries may be extended if the channel has to wait to become active.

    The channel tries to connect long retry count number of times at this long interval, after trying the short retry count number of times at the short retry interval.

    This is valid only for channel types of sender, cluster-sender, server, and cluster-receiver. It is also valid for requester channels on z/OS if you are using CICS. It may be set from zero through 999 999. On z/OS using CICS, it may be set from zero through 999.

    LU 6.2 mode name (MODENAME)

    This is for use with LU 6.2 connections. It gives extra definition for the session characteristics of the connection when a communication session allocation is performed.

    When using side information for SNA communications, the mode name is defined in the CPI-C Communications Side Object or APPC side information and this attribute should be left blank; otherwise, it should be set to the SNA mode name.

    The name must be one to eight alphanumeric characters long.

    It is not valid for receiver or server-connection channels.

    LU 6.2 transaction program name (TPNAME)

    This is for use with LU 6.2 connections. It is the name, or generic name, of the transaction program (MCA) to be run at the far end of the link.

    When using side information for SNA communications, the transaction program name is defined in the CPI-C Communications Side Object or APPC side information and this attribute should be left blank. Otherwise, this name is required by sender channels and requester channels except on z/OS using CICS where it is required in the channel definition but is ignored unless the server is initiating the conversation.

    On platforms other than Compaq NonStop Kernel, the name can be up to 64 characters long. See Chapter 20, Setting up communication in Compaq NonStop Kernel for more information about that platform.

    If the remote system is WebSphere MQ for z/OS using CICS, the transaction is:

    * CKRC when you are defining a sender channel, or a server channel that acts as a sender
    * CKSV when you are defining a requester channel of a requester-server pair
    * CKRC when you are defining a requester channel of a requester-sender pair

    On other platforms, this should be set to the SNA transaction program name, unless the CONNAME contains a side-object name in which case it should be set to blanks. The actual name is taken instead from the CPI-C Communications Side Object, or the APPC side information data set.

    This information is set in a different way on other platforms; see the section in this book about setting up communication for your platform.

    Maximum message length (MAXMSGL)

    Specifies the maximum length of a message that can be transmitted on the channel.

    On WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for OS/2 Warp, and VSE/ESA, specify a value greater than or equal to zero, and less than or equal to the maximum message length for the queue manager. See the MAXMSGL parameter of the ALTER QMGR command in the WebSphere MQ Script (MQSC) Command Reference book for more information. On other platforms, specify a value greater than or equal to zero, and less than or equal to 4 194 304 bytes. On WebSphere MQ for z/OS, specify a value greater than or equal to zero, and less than or equal to 104 857 600 bytes.

    Because various implementations of WebSphere MQ systems exist on different platforms, the size available for message processing may be limited in some applications. This number must reflect a size that your system can handle without stress. When a channel starts up, the lower of the two numbers at each end of the channel is taken.

    Notes:

    1. If splitting of messages is not supported at either end of a channel, the maximum message size cannot be greater than the negotiated maximum transmission size.

    2. The IBM WebSphere MQ products that this edition of the book applies to all support message splitting. Other WebSphere MQ products do not support message splitting.

    3. For a comparison of the functions available, including the different maximum message lengths available see the WebSphere MQ Application Programming Guide.

    4. You may use a maximum message size of 0 which will be taken to mean that the size is to be set to the local queue manager maximum value.

    Maximum transmission size

    If you are using CICS for distributed queuing on z/OS, you can specify the maximum transmission size, in bytes, that your channel is allowed to use when transmitting a message, or part of a message. When a channel starts up, this value is negotiated between the sending and receiving channels and the lower of the two values is agreed. The maximum size is 32 000 bytes on TCP/IP, but the maximum usable size is 32 000 bytes less the message descriptor. On VSE/ESA, the maximum size is 64 000 bytes on SNA.

    Use this facility to ensure that system resources are not exceeded by your channels. Set this value in conjunction with the maximum message size, remembering to allow for message descriptors. An error situation may be created if the message size is allowed to exceed the transmission size, and message splitting is not supported.

    Notes:

    1. If channel startup negotiation results in a size less than the minimum required for the local channel program, no messages can be transferred.

    Message channel agent name (MCANAME)

    This attribute is reserved and should not be used.

    Message channel agent type (MCATYPE)

    For WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for OS/2 Warp, this attribute may be specified as a 'process' or a 'thread'. This parameter is valid for channel types of sender, cluster-sender (on WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp), server, requester, or cluster-receiver. On WebSphere MQ for z/OS, it is supported only for channels with a channel type of cluster-receiver. The MCA type is used when the channel is started locally to determine how the channel is run.

    Advantages of running as a process include:

    * Isolation for each channel providing greater integrity
    * Job authority specific for each channel
    * Control over job scheduling

    Advantages of threads include:

    * Much reduced use of storage
    * Easier configuration by typing on the command line
    * Faster execution - it is quicker to start a thread than to instruct the operating system to start a process

    For channel types of sender, server, and requester, the default is 'process'. For channel types of cluster-sender and cluster-receiver, the default is 'thread'. These defaults can change during your installation.

    If you specify 'process' on the channel definition, a RUNMQCHL process is started. If you specify 'thread', the MCA runs on a thread of the RUNMQCHI process. On the machine that receives the inbound allocates, the MCA runs as a thread or process depending on whether you use inetd or RUNMQLSR.

    Message channel agent user identifier (MCAUSER)

    This is not valid for z/OS using CICS; it is not valid for channels of client-connection type.

    This attribute is the user identifier (a string) to be used by the MCA for authorization to access WebSphere MQ resources, including (if PUT authority is DEF) authorization to put the message to the destination queue for receiver or requester channels.

    On WebSphere MQ for Windows, the user identifier may be domain-qualified by using the format, user@domain, where the domain must be either the Windows systems domain of the local system or a trusted domain.

    If this attribute is blank, the MCA uses its default user identifier.

    Message exit name (MSGEXIT)

    Specifies the name of the user exit program to be run by the channel message exit. On AIX, Compaq Tru64 UNIX, HP-UX, iSeries, Linux, OS/2 Warp, Solaris, Windows systems, and z/OS this can be a list of names of programs that are to be run in succession. Leave blank, if no channel message exit is in effect.

    The format and maximum length of this attribute depend on the platform, as for Receive exit name (RCVEXIT).

    The message exit is not supported on client-connection or server-connection channels.

    Message exit user data (MSGDATA)

    Specifies user data that is passed to the channel message exits.

    In WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, Windows systems, and z/OS, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, you can run a sequence of message exits. The limitations on the user data length and an example of how to specify MSGDATA for more than one exit are as shown for RCVDATA. See Receive exit user data (RCVDATA).

    On other platforms the maximum length of the string is 32 characters.

    Message-retry exit name (MREXIT)

    Specifies the name of the user exit program to be run by the message-retry user exit. Leave blank if no message-retry exit program is in effect.

    The format and maximum length of the name depend on the platform, as for Receive exit name (RCVEXIT).

    This parameter is only valid for receiver, cluster-receiver, and requester channels. It is not supported on WebSphere MQ for z/OS.

    Message-retry exit user data (MRDATA)

    This is passed to the channel message-retry exit when it is called.

    This parameter is only valid for receiver, cluster-receiver, and requester channels. It is not supported on WebSphere MQ for z/OS.

    Message retry count (MRRTY)

    This is the number of times the channel will retry before it decides it cannot deliver the message.

    This attribute controls the action of the MCA only if the message-retry exit name is blank. If the exit name is not blank, the value of MRRTY is passed to the exit for the exit's use, but the number of retries performed (if any) is controlled by the exit, and not by this attribute.

    The value must be in the range 0 to 999 999 999. A value of zero means that no retries will be performed.

    This parameter is only valid for receiver, cluster-receiver, and requester channels. It is not supported on WebSphere MQ for z/OS.

    Message retry interval (MRTMR)

    This is the minimum interval of time that must pass before the channel can retry the MQPUT operation. This time interval is in milliseconds.

    This attribute controls the action of the MCA only if the message-retry exit name is blank. If the exit name is not blank, the value of MRTMR is passed to the exit for the exit's use, but the retry interval is controlled by the exit, and not by this attribute.

    The value must be in the range 0 to 999 999 999. A value of zero means that the retry will be performed as soon as possible (provided that the value of MRRTY is greater than zero).

    This parameter is only valid for receiver, cluster-receiver, and requester channels. It is not supported on WebSphere MQ for z/OS.

    Network-connection priority (NETPRTY)

    The priority for the network connection. Distributed queuing will choose the path with the highest priority if there are multiple paths available. The value must be in the range 0 through 9; 0 is the lowest priority.

    This parameter is valid only for cluster-receiver channels.

    This parameter is valid only on AIX, HP-UX, Linux, OS/2 Warp, z/OS without CICS, iSeries, Solaris, and Windows systems.

    Nonpersistent message speed (NPMSPEED)

    For WebSphere MQ for AIX, HP-UX, iSeries, Solaris and Windows systems, WebSphere MQ for z/OS without CICS, and MQSeries V5.1 for Compaq Tru64 UNIX and OS/2 Warp, you can specify the speed at which nonpersistent messages are to be sent. You can specify either 'normal' or 'fast'. The default is 'fast', which means that nonpersistent messages on a channel are not transferred within transactions. The advantage of this is that nonpersistent messages become available for retrieval far more quickly. The disadvantage is that because they are not part of a transaction, messages may be lost if there is a transmission failure or if the channel stops when the messages are in transit. See Fast, nonpersistent messages.

    This attribute is valid for sender, cluster-sender, server, receiver, cluster-receiver, and requester channels.

    Password (PASSWORD)

    You can specify a password of maximum length 12 characters, although only the first 10 characters are used.

    The password may be used by the MCA when attempting to initiate a secure LU 6.2 session with a remote MCA. It is valid for channel types of sender, server, requester, or client-connection.

    This does not apply to WebSphere MQ for z/OS except for client-connection channels.

    PUT authority (PUTAUT)

    Use this attribute to choose the type of security processing to be carried out by the MCA when executing:

    * An MQPUT command to the destination queue (for message channels) , or
    * An MQI call (for MQI channels).

    You can choose one of the following:

    Process security, also called default authority (DEF)
    The default user ID is used.

    On platforms, with Process security, you choose to have the queue security based on the user ID that the process is running under. The user ID is that of the process, or user, running the MCA at the receiving end of the message channel.

    The queues are opened with this user ID and the open option MQOO_SET_ALL_CONTEXT.
    Context security (CTX)
    The alternate user ID is used from the context information associated with the message.

    The UserIdentifier in the message descriptor is moved into the AlternateUserId field in the object descriptor. The queue is opened with the open options MQOO_SET_ALL_CONTEXT and MQOO_ALTERNATE_USER_AUTHORITY.
    Only Message Channel Agent security (ONLYMCA)
    The default user ID is used.

    On platforms, with ONLYMCA security, you choose to have the queue security based on the user ID that the process is running under. The user ID is that of the process, or user, running the MCA at the receiving end of the message channel.

    The queues are opened with this user ID and the open option MQOO_SET_ALL_CONTEXT.
    Alternate Message Channel Agent security (ALTMCA)
    This is the same as for ONLYMCA security but allows you to use context.

    This parameter is only valid for receiver, requester, cluster-receiver, and server-connection channels. Context security and alternate message channel agent security values are not supported on server-connection channels.

    Further details about:

    * Context fields and open options can be found in the WebSphere MQ Application Programming Guide.
    * Security can be found in the WebSphere MQ System Administration Guide for WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, or in the MQSeries System Administration book for your platform.

    Note:
    On WebSphere MQ for z/OS it is possible for two userids to be checked. Specific details of userids used by the channel initiator on z/OS can be found in the WebSphere MQ for z/OS System Setup Guide .

    .

    Queue manager name (QMNAME)

    This applies to a channel of client-connection type only. It is the name of the queue manager or queue manager group to which a WebSphere MQ client application can request connection.

    Receive exit name (RCVEXIT)

    Specifies the name of the user exit program to be run by the channel receive user exit. In WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, Windows systems, and z/OS, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp this can be a list of names of programs that are to be run in succession. Leave blank, if no channel receive user exit is in effect.

    The format and maximum length of this attribute depend on the platform:

    * On z/OS it is a load module name, maximum length 8 characters, except for client-connection channels where the maximum length is 128 characters.
    * On iSeries it is of the form:

    libname/progname

    when specified in CL commands.

    When specified in WebSphere MQ Commands (MQSC) it has the form:

    progname libname

    where progname occupies the first 10 characters, and libname the second 10 characters (both blank-padded to the right if necessary). The maximum length of the string is 20 characters.

    * On OS/2 and Windows it is of the form:

    dllname(functionname)

    where dllname is specified without the suffix ".DLL". The maximum length of the string is 40 characters.
    * On UNIX systems, Compaq OpenVMS Alpha, and Compaq NonStop Kernel it is of the form:

    libraryname(functionname)

    The maximum length of the string is 40 characters.

    On AIX, Compaq Tru64 UNIX, HP-UX, Linux, iSeries, OS/2 Warp, Solaris, Windows systems, and z/OS, you can specify a list of receive, send, or message exit program names. The names should be separated by a comma, a space, or both. For example:

    RCVEXIT(exit1 exit2)
    MSGEXIT(exit1,exit2)
    SENDEXIT(exit1, exit2)

    In WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, Windows systems, and z/OS, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, the total length of the string of exit names and strings of user data for a particular type of exit is limited to 500 characters. In WebSphere MQ for iSeries you can list up to 10 exit names. In WebSphere MQ for z/OS you can list up to eight exit names.

    Receive exit user data (RCVDATA)

    Specifies user data that is passed to the receive exit.

    In WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, z/OS, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp you can run a sequence of receive exits. The string of user data for a series of exits should be separated by a comma, spaces, or both. For example:

    RCVDATA(exit1_data exit2_data)
    MSGDATA(exit1_data,exit2_data)
    SENDDATA(exit1_data, exit2_data)

    In WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, the length of the string of exit names and strings of user data is limited to 500 characters. In WebSphere MQ for iSeries you can specify up to 10 exit names and the length of user data for each is limited to 32 characters. In WebSphere MQ for z/OS you can specify up to eight strings of user data each of length 32 characters.

    On other platforms the maximum length of the string is 32 characters.

    Security exit name (SCYEXIT)

    Specifies the name of the exit program to be run by the channel security exit. Leave blank if no channel security exit is in effect.

    The format and maximum length of the name depend on the platform, as for Receive exit name (RCVEXIT).

    Security exit user data (SCYDATA)

    Specifies user data that is passed to the security exit. The maximum length is 32 characters.

    Send exit name (SENDEXIT)

    Specifies the name of the exit program to be run by the channel send exit. In WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, z/OS, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, this can be a list of names of programs that are to be run in sequence. Leave blank if no channel send exit is in effect.

    The format and maximum length of this attribute depend on the platform, as for Receive exit name (RCVEXIT).

    Send exit user data (SENDDATA)

    Specifies user data that is passed to the send exit.

    In WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, z/OS, and Windows systems, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, you can run a sequence of send exits. The limitations on the user data length and an example of how to specify SENDDATA for more than one exit, are as shown for RCVDATA. See Receive exit user data (RCVDATA).

    On other platforms the maximum length of the string is 32 characters.

    Sequence number wrap (SEQWRAP)

    This is the highest number the message sequence number reaches before it restarts at 1. In z/OS using CICS, this number is of interest only when sequential delivery of messages is selected. It is not valid for channel types of client-connection or server-connection.

    The value of the number should be high enough to avoid a number being reissued while it is still being used by an earlier message. The two ends of a channel must have the same sequence number wrap value when a channel starts up; otherwise, an error occurs.

    The value may be set from 100 through 999 999 999 (1 through 9 999 999 for z/OS using CICS).

    Sequential delivery

    This applies only to z/OS using CICS. Set this to 'YES' when using sequential numbering of messages. If one side of the channel requests this facility, it must be accepted by the other side.

    There could be a performance penalty associated with the use of this option.

    For other platforms, the MCA always uses message sequence numbering.

    Short retry count (SHORTRTY)

    Specify the maximum number of times that the channel is to try allocating a session to its partner. If the initial allocation attempt fails, the short retry count is decremented and the channel retries the remaining number of times with an interval, defined in the short retry interval attribute, between each attempt. If it still fails, it retries long retry count number of times with an interval of long retry interval between each attempt. If it is still unsuccessful, the channel terminates.

    (Retry is not attempted if the cause of failure is such that a retry is not likely to be successful.)

    If the channel initiator or queue manager stops while the channel is retrying, the short retry count and long retry count are reset when the channel initiator or queue manager is restarted.

    The short retry count attribute is valid only for channel types of sender, cluster-sender, server, and cluster-receiver. It is also valid for requester channels on z/OS if you are using CICS. It may be set from zero through 999 999 999 (1 through 999 for z/OS using CICS, and the long and short retries have the same count).

    Note:
    On OS/2 Warp, iSeries, UNIX systems, and Windows systems, in order for retry to be attempted a channel initiator must be running. The channel initiator must be monitoring the initiation queue specified in the transmission queue that the channel in using.

    Short retry interval (SHORTTMR)

    Specify the approximate interval in seconds that the channel is to wait before retrying to establish connection, during the short retry mode.

    The interval between retries may be extended if the channel has to wait to become active.

    This attribute is valid only for channel types of sender, cluster-sender, server, and cluster-receiver. It is also valid for requester channels on z/OS if you are using CICS. It may be set from zero through 999 999. (0 through 999 for z/OS using CICS).

    SSL Cipher Specification (SSLCIPH)

    SSLCIPH defines a single CipherSpec for an SSL connection. Both ends of a WebSphere MQ SSL channel definition must include the parameter and the SSLCIPH values must specify the same CipherSpec on both ends of the channel. The value is a string with a maximum length of 32 characters.

    SSLCIPH is valid for all channel types. It is supported on AIX, HP-UX, Linux, iSeries, Solaris, Windows, and z/OS. It is valid only for channels with a transport type (TRPTYPE) of TCP. If the TRPTYPE is not TCP, the data is ignored and no error message is issued.

    SSLCIPH is an optional parameter.

    For more information on SSLCIPH, see WebSphere MQ Script (MQSC) Command Reference and WebSphere MQ Security.

    SSL Client Authentication (SSLCAUTH)

    SSLCAUTH is used to define whether the channel needs to receive and authenticate an SSL certificate from an SSL client.

    This parameter is valid on all channel types that can ever receive a channel initiation flow, except for sender channels. It is valid for receiver, server-connection, cluster-receiver, server, and requester channels.

    The value of SSLCAUTH can be set to OPTIONAL or REQUIRED. The default value is REQUIRED. If SSLCAUTH is set to OPTIONAL, and the peer SSL client sends a certificate, the certificate is processed as normal.

    You can specify a value for SSLCAUTH on a non-SSL channel definition, one on which SSLCIPH is missing or blank. You can use this to temporarily disable SSL for debugging without first having to clear and then reinput the SSL parameters.

    This parameter is valid on AIX, HP-UX, Linux, iSeries, Solaris, Windows, and z/OS

    SSLCAUTH is an optional parameter.

    For more information on SSLCAUTH, see WebSphere MQ Script (MQSC) Command Reference and WebSphere MQ Security.

    SSL Peer (SSLPEER)

    The SSLPEER parameter is used to check the Distinguished Name (DN) of the certificate from the peer queue manager or client at the other end of a WebSphere MQ channel. If the DN received from the peer does not match the SSLPEER value, the channel does not start.

    SSLPEER is an optional parameter. If a value is not specified, the peer DN is not checked when the channel is started.

    This parameter is valid for all channel types.

    This parameter is supported only on AIX, HP-UX, Linux, OS/2 Warp, iSeries, Solaris, Windows, and z/OS.

    On z/OS the maximum length of the parameter is 256 bytes. On all other platforms it is 1024 bytes.

    On z/OS the parameter values used are not checked. If you input incorrect values, the channel fails at startup, and error messages are written to the error log at both ends of the channel. A Channel SSL Error event is also generated at both ends of the channel. On platforms that support SSLPEER, other than z/OS, the validity of the string is checked when it is first input.

    You can specify a value for SSLPEER on a non-SSL channel definition, one on which SSLCIPH is missing or blank. You can use this to temporarily disable SSL for debugging without having to clear and later reinput the SSL parameters.

    For more information on using SSLPEER, see WebSphere MQ Script (MQSC) Command Reference and WebSphere MQ Security.

    Target system identifier

    This is for z/OS using CICS only. It identifies the particular CICS system where the sending or requesting channel transaction is to run.

    The default is blank, which means the CICS system where you are logged on. The name may be one through four alphanumeric characters.

    Transaction identifier

    This only applies to z/OS using CICS.

    The name of the local CICS transaction that you want to start. If you do not specify a value, the name of the supplied transaction for the channel type is used.

    Transmission queue name (XMITQ)

    The name of the transmission queue from which messages are retrieved. This is required for channels of type sender or server, it is not valid for other channel types.

    Provide the name of the transmission queue to be associated with this sender or server channel, that corresponds to the queue manager at the far side of the channel. The transmission queue may be given the same name as the queue manager at the remote end.

    Transport type (TRPTYPE)

    This does not apply to z/OS using CICS.
    0 (0 Ratings)
    [ 2467 views ] Leave a Comment

    IBM Websphere MQ Processes - Middleware News

    Sunday, May 6, 2012, 10:35 AM
    Categories: WebSphere MQ
    Posted By: Karthick

    IBM Websphere MQ Processes

    Processes

    AMQMTRBN . amqhasmn.exe - the logger.
    amqmsrvn.exe - COM server.
    amqmtbrn.exe - . amqpcsea.exe - the command server.
    amqrmppa.exe - channel process.
    amqrrmfa.exe - repository process (for clusters).
    amqsvc.exe - . amqxssvn.exe - shared memory server(s).
    amqzdmaa.exe - deferred message processor.
    amqzfuma.exe - OAM process.
    amqzlaa0.exe - queue manager agents (LQM agents).
    amqzllp0.exe - checkpoint processor.
    amqzxma0.exe - processing controller.
    runmqchi.exe - channel initiator. runmqlsr.exe - listener.

    Description of MQ tasks :

    When a queue manager is running, you see some or all of the following batch jobs running under the QMQM user profile in the MQ subsystem.
    Job name Function AMQALMPX The checkpoint processor that periodically takes journal checkpoints. AMQCLMAA Non-threaded TCP/IP listener. AMQCRSTA TCP/IP-invoked channel responder. AMQCRS6B LU62 receiver channel and client connection (see note). AMQFCXBA Broker worker job. AMQPCSEA PCF command processor. Handles PCF and remote administration requests. AMQRMPPA Channel process pooling job. AMQRRMFA Repository manager for clusters. AMQZDMAA Deferred message handler. AMQZFUMA Object authority manager (OAM). AMQZLAA0 Queue manager agents that perform the bulk of the work for applications that connect to the queue manager using MQCNO_STANDARD_BINDING. AMQZLAS0

    Queue manager agent. AMQZXMA0 The execution controller is the first job started by the queue manager. Deals with MQCONN requests. Starts agent processes to process MQ API calls. AMQZMGR0 Process controller. Used to start up and manage listeners and services. AMQZMUC0 Utility manager. Do critical utilities, as the journal chain manager. AMQZMUR0 Utility manager. Do critical utilities, as the journal chain manager. RUNMQBRK Broker control job. RUNMQCHI The channel initiator. RUNMQCHL Sender channel job that is started for each sender channel. RUNMQDLQ Dead letter queue handler. RUNMQLSR Threaded TCP/IP listener. RUNMQTRM Trigger monitor.
    0 (0 Ratings)
    [ 1097 views ] Leave a Comment

    Page 6 of 11  •  Prev 1 ... 4 5 6 7 8 ... 11 Next

Connect w/ Others

Member of the Month