Hitachi raidcom command builder (Community)

Build one raidcom command from structured arguments and validate it. Nothing is executed and no storage system is contacted: you get command text to review and run elsewhere. Unknown options, wrong value counts, missing required options, bad port names and out-of-range LDEV, LUN, pool and serial numbers are reported as errors with a fix. Example: {"command": "add ldev", "options": {"-pool": 0, "-ldev_id": 256, "-capacity": "100G"}, "model": "vsp-one-b28", "global": {"instance": 0}} → `raidcom add ldev -pool 0 -ldev_id 256 -capacity 100G -I0`. For many similar commands use raidcom_build_script, not repeated calls. When the user asks for a command, show them the `command` from the result.

Build the script for a recipe from its parameters (see raidcom_list_recipes). Lists such as ldev_ids accept ranges: ["100-109"]. Example: recipe provision-fc-volumes with {"pool": 0, "ldev_ids": ["100-103"], "capacity": "100G", "ports": ["CL1-A", "CL2-A"], "host_grp": "esx01", "host_mode": "VMWARE_EX", "wwns": ["210000e08b0256f8"]}. Returns the script and the individual commands. Nothing is executed.

Build a shell script of raidcom commands from steps. Each step is a command with options, optionally repeated with `foreach` (every combination) or `zip` (values advance together), so "create LDEVs 100 to 109 in pool 0, then map each to port CL1-A" is two steps. Every expanded command is validated; the script is returned only if all of them are valid, otherwise you get the errors per step. The script checks each command's exit status, adds `raidcom get command_status` after asynchronous commands, and can lock the resource group and log in (credentials are read from RAIDCOM_USER and RAIDCOM_PASSWORD in the user's shell, never written into the script). Nothing is executed.

Validate and explain a raidcom command line the user already has (for example one pasted from a runbook). It is parsed, not executed: shell operators such as ; | & > are refused. Returns the normalised command, what each option means, and every problem found. Credentials after -login are dropped.

Everything needed to build one raidcom command: what it does, which models support it, whether it is read-only, destructive or asynchronous, each syntax form, every option with the number and kind of values it takes (and the words it accepts, where it accepts only a few), and examples. Call it before raidcom_build_command when you are unsure which options a command needs or which of its syntax forms fits the request.

Find raidcom commands. Use this first when you do not know the exact command name. With no arguments, lists every object (ldev, lun, host_grp, pool, ...) with the actions available on it. With `query` (plain words, e.g. "map a volume to a host group", "grow a pool", "show free ldev ids"), ranks matching commands and rates the confidence of the top result. With `action` and/or `object`, lists exactly those commands. Then call raidcom_describe_command, or raidcom_build_command if you already know the options.

Ready-made workflows: provision volumes to an FC, iSCSI or NVMe/TCP host, create or grow a pool, create a mainframe (3390) pool, extend or delete volumes, create a command device, reclaim zero pages, read-only inventory, copy groups. With no arguments lists them. With `recipe`, shows its parameters and steps. With `query`, ranks recipes by keyword. Use raidcom_build_recipe to turn one into a script.

Valid parameter ranges for a storage model (serial number, LDEV ID, pool ID, LU number, port names), taken from the Command Reference appendices. Without `model`, lists the models.