Interesting comment, Robert.
Assuming that the storage operand field of VPKZ/VUPKZ is defined with an
appropriate length, you make a valid point.
Had I been been paying closer attention when this was architected, I might have
suggested that the VSI instruction format (added specifically in support of
VPKZ and VUPKZ) incorporate the length as part of the second operand ... that
is, an L2 field instead of an I3 field. That way, you could code the
instruction the way you suggested, or as is done for other storage operands
with an embedded length, e.g.,
vupkz 1,storage_op
vupkz 1,storage_op(23)
vupkz 1,543(21,12)
However, as is obvious with recent changes in the architecture, IBM tends to
sneak new features into previously reserved operand bits. If some future
enhancement added function to the I3 field, the suggestion I made above could
become awkward.
Perhaps you can simply dodge the coding inconvenience by cobbling up your own
macro to incorporate the second operand's length into the I3 field.