There's no way it would be practical to support general DC syntax within evaluation of a numeric expression. Even supporting a space not enclosed in quotes (apart from quotes used for attributes) within a machine instruction operand or macro operand is problematic. What if it is used in a numeric expression within a DC expression itself? The recursion logic for expressions is already somewhat of a nightmare.
Also, HLASM syntax currently takes care to use only characters which are common to all main EBCDIC SBCS code pages (apart from the three NLS characters allowed in names, which are defined by their code points rather than by their appearance), and it doesn't even use all of those. Square brackets are not invariant EBCDIC codes. Sorry, but this type of solution is of totally disproportion complexity compared with the minor impact of the problem that it would solve. Of course, I can't speak for the IBM HLASM team now I'm retired, but I remember enough about the product internals to know what is even remotely feasible. An alternative solution which has been requested is a shift operator valid in Assembler expressions, so you could use something like C' '<<8 instead of C' '*X'100' (although the notation would need plenty of thought). I think something like this would be acceptable from a language point of view. However, there's an unfortunate internal limitation that all operators are currently represented by one-byte codes and all possible one-byte codes for this purpose are already in use, so it would not be easy to implement. (Built-in functions use some double-level codes to get round this, but the first bytes for those are special cases). If a way could be found to allow for more operators, there were other ones which could also be useful, such as the minimum number of binary digits needed to represent a numeric value (a sort of special case log to the base 2). Jonathan Scott -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Seymour J Metz Sent: 30 March 2026 14:01 To: [email protected] Subject: Re: Complex immediate operands That sounds different from what I asked about. With new syntax there's no conflict with existing code. Something like the below would have no ambiguity: IILH R1,[DC AL1(C' ',0)] -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Jonathan Scott <[email protected]> Sent: Monday, March 30, 2026 8:01 AM To: [email protected] <[email protected]> Subject: Re: Complex immediate operands External Message: Use Caution It's been requested before, but rejected, as the idea of allowing DC-like constants directly within a numeric expression is obviously incompatible with the existing language. For example, this is already valid: AL1 EQU 1 LA 0,AL1(2,3) Of course, in theory one could have different types of numeric expressions in different contexts, but that would be a huge and impractical change for very little benefit. Jonathan Scott -----Original Message----- From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Seymour J Metz Sent: 30 March 2026 12:53 To: [email protected] Subject: Complex immediate operands I use 16 bit immediate operand instructions to load pad bytes. Typically I code X'4000' or 256*C'0'' for a blank pad, but it would be more readable if there were syntax to treat AL1(C' ',0) as a DC operand. Is there an open requirement along those lies? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
