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.