Online scoring error messages

The following error messages appear in the IBM Machine Learning for z/OS online scoring service when requests fail due to authentication issues, deployment problems, validation errors, runtime failures, or internal scoring service errors.

ALNB101E


Message	Invalid user role
Explanation	This error means the authenticated user does not have a role authorized to perform online scoring operations. MLz online scoring requires one of the following roles: sysadm (system administrator), mladm (machine learning administrator), apiuser (API user), devuser (model developer), or appuser (application developer). If the user's role is not one of these five authorized roles, the scoring request is rejected.

ALNB102E


Message	Invalid token
Explanation	This error means the JWT token provided in the Authorization header of the online scoring request is not valid. The token may be malformed, corrupted, or not properly formatted as a JWT. To resolve this, generate a new authentication token using the token generation API (POST /auth/generateToken) with valid username and password credentials. Ensure the token is included in the Authorization header as "Bearer <token>" when making online scoring requests. If the token was recently generated and is still failing validation, verify that the token string was copied completely without truncation or modification.

ALNB103E


Message	Expired token
Explanation	This error means the JWT token provided in the Authorization header of the online scoring request has expired and is no longer valid for authentication. MLz uses JWT tokens for API authentication, and these tokens have a configurable expiration time (default is 13 hours or 46,800,000 milliseconds). When a token expires, it can no longer be used to authenticate scoring requests. Generate a new token using the token generation API (either with username/password or user certificate) and retry the scoring request with the new token in the Authorization header. For token generation, see the token generation API documentation.

ALNB201E


Message	Deployment {param} already exists
Explanation	This error means the deployment identifier specified in the request conflicts with an existing deployment in the target scoring service. The conflict can occur with the deployment name or the serving ID. For deployment names, each deployment must have a unique name within the MLz environment. For serving ID, only one deployment with a given serving ID can exist within a specific scoring group ID, though the same serving ID can be reused across different scoring groups if the deployments share an identical model schema. Check whether another deployment already uses the requested name or serving ID in the target scoring service or scoring group, and either choose a different identifier or remove the conflicting deployment before retrying.

ALNB202E


Message	engineType {param} is invalid
Explanation	This error means the supplied `engineType` value is not supported for online deployment creation or update. MLz supports the following engine types for online deployments: `spark`, `pmml`, `scikit`, `xgboost`, `arima`, `sarimax`, `onnx`, and `watfore`. The `engineType` is a required field in the `deploy_info` object when creating or updating an online deployment. Verify that the `engineType` value in the deployment request matches one of the supported values exactly, including correct capitalization and spelling. For reference, see the online deployment creation API documentation.

ALNB203E


Message	maxBatchSize {param} is invalid
Explanation	This error occurs when creating or updating an ONNX model online deployment with micro-batching enabled and the specified `maxBatchSize` value is outside the valid range. The `maxBatchSize` parameter defines the maximum number of scoring requests that can be batched together for inference and must be a positive integer. Verify that the `maxBatchSize` value in the deployment request falls within this range. Note that micro-batching is only available for ONNX models with at least one dimension for dynamic input, and the `batching` parameter must be set to true for `maxBatchSize` to take effect. For reference, see the online deployment creation and update API documentation.

ALNB204E


Message	maxLatencyInMs {param} is invalid
Explanation	This error means the `maxLatencyInMs` value provided for online micro-batching is not valid. The `maxLatencyInMs` parameter specifies the maximum latency in milliseconds for processing each scoring batch when micro-batching is enabled for ONNX model deployments. This parameter is only applicable when `batching` is set to true for ONNX model online deployments. Verify that the provided value is a positive integer. If micro-batching is not enabled, do not specify this parameter. For reference, see the online deployment creation and update API documentation for ONNX micro-batching configuration.

ALNB205E


Message	The model cannot be deployed with micro-batching enabled
Explanation	This error means the ONNX model being deployed does not support micro-batching because it lacks dynamic input dimensions. Micro-batching inference is only available for ONNX models that have at least one dimension for dynamic input. Models with only fixed dimensions cannot use micro-batching. To resolve this, either deploy the model without enabling the micro-batching option (set `batching: false` in the deployment request), or use a different ONNX model that has dynamic input dimensions. For reference, see the deployment configuration sections for ONNX models with micro-batching.

ALNB206E


Message	Unable to deploy the model with zaiu=true. Scoring server is not running on a system with integrated AI accelerator available
Explanation	This error occurs when attempting to create or update an ONNX model deployment with the `zaiu` flag set to `true`, but the target scoring server does not have access to the IBM z16™ on-chip AI accelerator. The `zaiu` parameter enables hardware-accelerated scoring using the Telum processor's integrated AI unit, which requires specific hardware and software prerequisites. To use `zaiu=true`, the scoring server must run on IBM z16 or z17 hardware, have the IBM Z Deep Neural Network Library (zDNN) installed on the system, and have the `AIE_INSTALL_DIR` environment variable set to the zDNN installation directory (default: `/usr/lpp/IBM/aie`). Additionally, the ONNX model must have been imported on a core service running on hardware equal to or higher than the scoring server's hardware level, as zDLC compilation generates model versions compatible only up to that hardware level. Verify that the scoring server meets these requirements, or deploy the model with `zaiu=false` to run on CPU instead. For reference, see the sections on configuring the ONNX compiler service and deploying ONNX models with AI acceleration.

ALNB221E


Message	Failed to load model from metadata repository: {param}
Explanation	This error occurs when the MLz scoring service cannot retrieve the model artifact from the metadata repository during deployment operations. The {param} placeholder typically contains details about which model or artifact failed to load. Common causes include: the model artifact referenced by `artifactVersionHref` does not exist in the repository, the repository service is unavailable or experiencing connection issues, the model artifact stored in the repository is corrupted or incomplete, or there are Db2 connectivity problems preventing access to the metadata tables. Verify that the `artifactVersionHref` in the deployment request points to a valid model version that exists in the repository. Check the repository service status and Db2 connection. Review the scoring service logs for detailed error information about the repository access failure. If using Db2 as the metadata repository, confirm that the repository service can connect to Db2 and that the model artifact tables are accessible.

ALNB222E


Message	Model artifact {param} not found in metadata repository
Explanation	This error occurs during deployment operations when the scoring service cannot locate the referenced model artifact in the MLz metadata repository. The `artifactVersionHref` parameter specifies the URI for the model version in the format `/v3/ml_assets/models/{modelId}/versions/{versionId}`. This error typically happens when creating, updating, or reloading a deployment if the model version referenced in `artifactVersionHref` no longer exists in the repository, was deleted, or the href contains an incorrect model ID or version ID. Verify that the model and version still exist by using the Get models API or Get model version API. If the model was deleted, you must either restore it or update the deployment to reference a different valid model version. Also confirm that the metadata repository connection is functioning properly.

ALNB223E


Message	Model version href {param} is invalid
Explanation	This error means the supplied `artifactVersionHref` does not meet the required format or does not reference a valid model version in the MLz repository. The `artifactVersionHref` must be a valid URI in the format `/v3/ml_assets/models/{model_id}/versions/{version_id}`, where both the model ID and version ID must correspond to an existing model and version stored in MLz. Common causes include providing a malformed URI, referencing a model or version that does not exist, or using an incorrect model ID or version ID. Verify that the model and version exist using the Get models API or Get model version API, then ensure the `artifactVersionHref` value matches the exact format and IDs returned by those APIs.

ALNB224E


Message	Model type {param} is not supported by scoring runtime {param}
Explanation	This error occurs during online deployment creation when the specified model type is incompatible with the selected scoring runtime engine. MLz supports the following engine types for online deployments: spark, pmml, scikit, xgboost, arima, sarimax, onnx, and watfore. Each model type must be deployed with its corresponding compatible engine. For example, a Scikit-learn model requires the scikit engine, an ONNX model requires the onnx engine, and a PMML model requires the pmml engine. Verify that the engineType specified in the deploy_info matches the model type being deployed. Check the model's metadata using the Get model version API to confirm the model type, then ensure the engineType in the deployment request corresponds to that model type. For reference, see the Create online deployment API documentation for supported engine types and the supported algorithms, data sources, data types, and model types documentation for model type details.

ALNB225E


Message	Runtime {param} not found in metadata repository
Explanation	This error occurs during online deployment operations when MLz cannot find the specified runtime in the metadata repository. For Spark models that use custom runtimes, the runtime must exist in the repository and be properly associated with the model version before deployment. The runtime is referenced by its ID in the model's metadata. Common causes include: the custom runtime was deleted after being associated with the model, the runtime ID in the model metadata is invalid or corrupted, or the model was migrated from another environment without the corresponding runtime. To resolve this, verify the runtime exists by querying `/v4/runtimes/{runtime_id}` using the Get custom runtime API. If the runtime is missing, either recreate it with the same ID and configuration, or update the model metadata to reference a valid runtime using the Model Patch API. For models that do not require custom runtimes, verify the `engineType` specified in the deployment request matches a supported type (spark, pmml, scikit, xgboost, arima, sarimax, onnx, watfore). For reference, see the custom runtime documentation section on using custom runtimes for Spark models.

ALNB226E


Message	Failed to load runtime from metadata repository: {param}
Explanation	This error occurs during deployment operations when the MLz scoring service cannot retrieve the specified runtime information from the metadata repository. Runtimes, including both system-defined and custom runtimes, are stored in the metadata repository and must be loaded when creating or updating deployments. Common causes include: the runtime ID referenced in the deployment does not exist in the repository, the runtime was deleted after being associated with a deployment, or there is a database connectivity issue preventing access to the runtime metadata. Check that the runtime ID specified in the deployment configuration is valid by using the Get custom runtime API (`GET /v4/runtimes/{runtime_id}`). Verify the metadata repository database connection is functioning properly. If the runtime was recently deleted, you may need to recreate it or update the deployment to reference a different runtime. For custom runtimes used with Spark models, ensure the runtime was properly created with the required custom libraries before attempting deployment.

ALNB227E


Message	Model is not supported by the SnapML runtime: {param}
Explanation	This message indicates that the model being deployed is not compatible with the SnapML scoring runtime. SnapML models in MLz are trained using the Snap ML library but are saved as PMML model type and deployed with the SnapML engine. Only specific SnapML model types are supported for deployment: snapml.RandomForestClassifier, snapml.RandomForestRegressor, snapml.BoostingMachineClassifier, snapml.BoostingMachineRegressor, and certain sklearn, lightgbm, and xgboost variants when trained through SnapML. The {param} value typically contains the specific model framework or type information being validated. For reference, see the model types section in the supported algorithms documentation.

ALNB261E


Message	Unable to get deployment {param} from metadata repository: {param}
Explanation	This error occurs when the MLz scoring service cannot retrieve deployment information from the metadata repository. The scoring service queries the Db2 metadata repository to fetch deployment details needed for scoring operations. Common causes include the deployment ID not existing in the repository, database connectivity issues between the scoring service and the metadata repository, or insufficient database privileges for the scoring service user. Check the scoring service and Core Services logs for detailed error information. Verify that the deployment exists using the Get deployment detail API, confirm the metadata repository connection is active, and ensure the scoring service has appropriate database access permissions.

ALNB262E


Message	Another request is deploying the deployment {param}
Explanation	This error means another request is currently deploying or updating the specified deployment and the operation has not yet completed. MLz prevents concurrent deployment operations on the same deployment to avoid conflicts. When a deployment is created in async mode, it enters an INITIALIZING state while the scoring service processes the deployment request. During this time, or while any other deployment operation is in progress, subsequent requests to deploy or update that same deployment will be rejected with this error. Wait for the current deployment operation to complete (status becomes ACTIVE) before attempting another deployment operation on the same deployment. You can check the deployment status using the Get deployment detail API.

ALNB263E


Message	Another request is reloading the deployment {param}
Explanation	This error means another request is currently reloading the specified deployment, and MLz does not allow concurrent reload operations on the same deployment. A deployment reload typically occurs when updating deployment metadata such as the model version, engine type, scoring group, or other deployment configuration through the update deployment API. Only one reload operation can be in progress for a given deployment at any time. Wait for the current reload operation to complete, then retry your request. You can check the deployment status using the get deployment detail API to confirm when the deployment returns to an ACTIVE state.

ALNB264E


Message	Another request is updating the deployment {param}
Explanation	This error means MLz rejected the request because the target deployment is already being modified by another in-progress request. In Online Scoring, deployment update operations such as changing deployment settings or model version are handled as managed update actions, and MLz does not allow overlapping update activity against the same deployment at the same time. Wait for the other deployment update request to finish, then retry the operation. If this error keeps occurring, check whether multiple users, clients, scripts, or automation jobs are attempting to update the same deployment concurrently. Verify which deployment is identified by `{param}`, confirm that no other update or administrative action is still in progress for that deployment, and then retry once the deployment is no longer being updated. For related deployment update procedures, see the online scoring deployment update sections in the MLz documentation.

ALNB265E


Message	Another request is removing the deployment {param}
Explanation	This error means MLz rejected the request because the specified deployment is already in the middle of a removal operation started by another request. In the online scoring deployment lifecycle, deployment deletion is handled as a distinct operation, and MLz does not allow overlapping removal actions against the same deployment at the same time. Check whether another user, process, or API call has already submitted a delete request for that deployment. If Dual Control is enabled, also check whether a delete deployment request has already been created and is still awaiting response or completion. Wait for the current removal operation to finish, then retry only if the deployment still exists and further action is needed.

ALNB266E


Message	Another request is processing the deployment {param}
Explanation	This error occurs when attempting to perform an operation on a deployment that is already being processed by another concurrent request. MLz uses locking mechanisms to prevent conflicting operations on the same deployment, such as simultaneous update, delete, or reload operations. When a deployment operation is in progress, subsequent requests targeting that same deployment are rejected until the current operation completes. Wait for the current operation to finish, then retry your request. If the deployment appears stuck in a processing state, check the scoring service logs to verify the status of the ongoing operation. You can also use the Get deployment detail API to check if the deployment status has returned to ACTIVE before retrying.

ALNB267E


Message	Deployment {param} not found in metadata repository
Explanation	This error means the scoring service could not find the specified deployment in the MLz metadata repository. The `{param}` placeholder represents either a deployment ID (auto-generated GUID) or a serving ID (user-provided identifier) that was used in the scoring request. Deployments are identified in one of two ways: if a serving ID was provided during deployment creation, scoring requests must use that serving ID; otherwise, use the auto-generated deployment ID. Common causes include using an incorrect identifier, attempting to score against a deployment that was deleted, or using a serving ID when the deployment was created without one (or vice versa). Verify the deployment exists by checking the deployment list through the MLz dashboard or the Get deployment detail API, and confirm you are using the correct identifier type that matches how the deployment was created.

ALNB268E


Message	Failed to get {param} due to internal error: {param}
Explanation	This error means the online scoring service failed while attempting to retrieve the requested value identified by `{param}`, and the operation ended with an unexpected internal exception. Because the message is generic and does not identify the failing subsystem, treat it as an internal scoring-service error rather than a validation problem. Check the online scoring service logs for the underlying exception details and stack trace. Use the log entries at the time of the request to determine what resource or operation associated with `{param}` failed, then correct that underlying condition and retry.

ALNB281E


Message	Failed to remove deployment: {param}
Explanation	This error occurs when the MLz online scoring service fails to remove a deployment from its runtime environment. The {param} placeholder typically contains the deployment ID or serving ID that could not be removed. Common causes include the deployment being actively used for scoring requests, the scoring service being in an inconsistent state, or internal errors during the unload process. Check the scoring service logs for detailed error information about why the removal failed. Verify the deployment exists and is not currently processing scoring requests. If the scoring service is part of a cluster, ensure all nodes are healthy. For proper deployment deletion, refer to the the DELETE deployment API documentation.

ALNB301E


Message	Required field {param} not found in the input
Explanation	This error means the scoring request body is missing an input field that the deployed model requires. In MLz online scoring, the request data must match the model schema expected by the deployment, including required field names. If a required field is omitted, MLz rejects the request during input validation before scoring runs. Check the JSON payload being sent to the online scoring API and verify that every required input column defined for the deployed model is present, spelled correctly, and placed in the expected request structure. If the request was generated by an application, also confirm that no preprocessing step removed or renamed the field before submission. For additional information, see the online scoring API and deployment documentation sections in the MLz documentation.

ALNB302E


Message	Field {param} in the input is redundant
Explanation	This error means the scoring request includes a field that is not defined in the deployment's input schema. MLz validates all incoming scoring requests against the model's expected input schema. When using the JSON object format with "fields" and "values" arrays, only field names that exist in the deployment's input schema should be included in the "fields" array. When using the JSON array format with key-value pairs, only keys that match field names in the input schema should be present. Remove the extra field from the scoring request, or verify the deployment's input schema to confirm which fields are expected. You can retrieve the input schema using the Get deployment detail API or the Get model version API to see the exact field names and types the model expects.

ALNB303E


Message	Invalid input: {param}
Explanation	This error means the scoring request contains an invalid value for the specified parameter. The MLz online scoring service validates all input fields against the deployment's input schema before scoring. Common causes include: the parameter value does not match the expected data type (for example, passing a string when a number is expected), a required field is missing from the request, the input JSON structure is malformed (not a valid JSON object or array), or for PMML models, the value does not conform to the domain definitions in the PMML file. Check the deployment's input schema to verify the expected field names, data types, and required fields. Ensure the scoring request uses the correct JSON format (either fields/values object format or array of key-value objects). For PMML models with strict domain validation, you can optionally set the environment variable `PMML_TREAT_INVALID_VALUE_AS_MISSING=true` in the scoring service's .profile to treat invalid values as missing rather than rejecting the request. For reference, see the online scoring API documentation for request body format requirements.

ALNB304E


Message	Unsupported data type {param}
Explanation	This error occurs during online scoring when the input data contains a data type that is not supported by the ONNX model or the MLz ONNX scoring engine. ONNX models support specific tensor data types such as float32, float64, int32, int64, and others defined in the ONNX specification. The error indicates that the value provided for the parameter named in the message does not match one of the supported types expected by the model's input schema. Verify the input schema of your ONNX model using the Get model version API to confirm the expected data types for each input field, then ensure your scoring request provides data in the correct format. For reference on ONNX model support and limitations, see the "Supported algorithms, data sources, data types, and model types" section of the MLz documentation.

ALNB305E


Message	Cannot perform scoring operation: {param}
Explanation	This error indicates that the online scoring request failed input validation. The {param} placeholder identifies the specific validation issue encountered. Common causes include missing required fields from the deployment's input schema, incorrect data types for field values, or a malformed JSON payload structure. The scoring request must provide all required fields defined in the deployment's input schema and use one of the following formats: A JSON object containing fields and values arrays A JSON array containing key-value pairs for each record Verify that the request payload matches the deployment's input schema requirements, includes all required fields, and uses the correct data type for each field. Additionally, when scoring through the WOLA interface, this error can also occur if the deployed model contains multiple dynamic dimension sizes in its input or output schemas. WOLA scoring requires fixed-size input and output schemas and does not support multiple dynamic dimensions. In this case, you may see output similar to the following: Scoring failed with return code: 0008 Scoring error message ID: ALNB305E Scoring error message content: Cannot perform scoring operation: Method with name `getlstminputinput` not found in input class To resolve this issue, ensure that the model's input and output schemas use fixed dimension sizes before importing and deploying the model. For details about the expected input format, see the online scoring API documentation.

ALNB306E


Message	Class {param} not found
Explanation	This error occurs when the MLz scoring service cannot locate a required Java class during PMML model scoring. The missing class name is shown in the error message. Common causes include missing custom libraries in the deployment configuration, an incomplete custom runtime definition, or missing Java dependencies required by specific PMML transformations in the model. If the model uses custom transformations or functions, verify that all required JAR files are included in a custom library and properly associated with the model through a custom runtime. Check the scoring service logs for the full class name and stack trace. For models requiring custom libraries, see the documentation on using custom runtimes for Spark models, which also applies to PMML models that need additional Java dependencies.

ALNB307E


Message	{param}
Explanation	This error indicates an input validation issue occurred during online scoring. The error message is dynamically generated and will contain specific details about the validation failure. Common causes include data type mismatches, invalid field values, or schema constraint violations in the scoring request payload. Check the scoring service logs for the complete error message and details about which input field or validation rule failed.

ALNB401E


Message	Internal error: {param}
Explanation	This error indicates an unexpected exception occurred in the MLz online scoring service during model execution or scoring operations. The `{param}` placeholder contains additional context about the failure. Check the scoring service logs for detailed error information and stack traces to identify the root cause.

ALNB402E


Message	Unhandled exception of type {param} with message: {param}
Explanation	This error indicates an unexpected exception occurred in the MLz online scoring service. The error message includes the exception type and details to help identify the issue. Check the scoring service logs for detailed error information and stack traces to identify the root cause.

ALNB432E


Message	SnapML server is not running
Explanation	This error means MLz attempted to use the SnapML scoring runtime for an online scoring request, but the SnapML server process was not available. In the MLz documentation, SnapML is called out as a supported online scoring runtime, and SnapML models are documented together with PMML models for online scoring behavior such as request timeout handling. If this error occurs, verify that the deployment is intended to use a SnapML model and that the associated online scoring service is active and fully started. Also check whether the environment was prepared for the required runtime support. The MLz documentation notes prerequisite setup such as IBM Z Deep Neural Network Library (zDNN) when using certain ONNX or SnapML scoring capabilities on supported z/OS levels. For troubleshooting, review the online scoring service logs to identify why the SnapML server is not running or failed to start.

ALNB433E


Message	Failed to launch the SnapML server: {param}
Explanation	This error means MLz was unable to start the SnapML scoring server for an online deployment. The `{param}` value should contain additional failure detail returned at launch time. Check that the deployment is using a supported online scoring configuration for the model and engine. In the MLz documentation, SnapML is described as an online scoring model type, and the online deployment APIs document runtime options such as deployment `engineType` and request `timeout` for PMML and SnapML online scoring. Also verify that any required prerequisite software for the target environment is installed when applicable. If you plan to use micro-batching inference or on-chip AI acceleration for ONNX or SnapML scoring on supported z/OS levels, the IBM Z Deep Neural Network Library (zDNN) prerequisite must be installed. To diagnose the exact startup failure, review the Online Scoring service logs, then use the detail in `{param}` together with the log entries to identify the missing dependency, invalid runtime setting, or environment problem that prevented the SnapML server from starting.

ALNB434E


Message	Timeout is supported for PMML and SnapML model types only.
Explanation	This error occurs when attempting to configure a scoring timeout for a deployment that uses a model type other than PMML or SnapML. MLz supports an optional timeout parameter for online scoring requests, but this feature is limited to PMML and SnapML engine types only. The timeout parameter is specified in milliseconds (valid range: 1–60,000) in the `deploy_info` object during deployment creation or update. If the deployment uses a different engine type such as Spark, scikit-learn, XGBoost, ARIMA, SARIMAX, ONNX, or Watson Core Time Series (watfore), the timeout parameter is not supported and must be omitted from the request. Verify the `engineType` of the deployment and remove the timeout parameter if the model is not PMML or SnapML. For reference, see the online deployment creation and update API documentation.

ALNB435E


Message	Scoring request timed out.
Explanation	This error means the scoring request exceeded the configured timeout duration for the deployment. MLz allows you to set an optional timeout value (1 to 60,000 milliseconds) on PMML and SnapML online deployments to automatically cancel long-running inferencing requests. By default, if no timeout is specified, scoring requests run until completion. Once a timeout is configured, it applies uniformly to all incoming online scoring requests for that deployment. If a request completes within the timeout, it returns normally. If it exceeds the timeout, MLz cancels the request and returns this error. To resolve, either increase the timeout value using the update online deployment API (PATCH `/v1/deployments/{deployment_id}` with path `/deploy_info/timeout`), or remove the timeout setting entirely to allow requests to run until completion. Set a reasonable timeout value—a very low timeout may reject most inferencing requests and cause real-time scoring failures. Note that timeout does not apply to online batch scoring through JES. For reference, see the deployment configuration sections on scoring timeout.

ALNB436E


Message	Invalid timeout value. Timeout must be a positive integer.
Explanation	This error occurs when creating or updating an online deployment with an invalid timeout value in the `deploy_info.timeout` field. The timeout parameter specifies the maximum duration, in milliseconds, that a scoring request can run before being canceled. MLz requires the timeout to be a positive integer within the valid range of 1 to 60,000 milliseconds. Common causes include providing a negative number, zero, a non-integer value, or a value exceeding 60,000 milliseconds. Verify that the timeout value in your deployment request is a positive integer between 1 and 60,000. Note that timeout is supported only for online deployments with PMML or SnapML engine types and is not applicable to batch scoring. For reference, see the deployment creation and update API documentation sections on timeout configuration.