I too would like a more free form syntax, particularly allowing greater width.

The ability to drop a dependent but not labelled Using would sometimes be 
useful, and yes I know there are ways around this but they are all a little 
cumbersome.

But most of all would be some way to imply the length of the second operand on 
SS format instructions. I cant begin to imagine how much time I have spoent 
counting the length of some second operand and having to manually code its 
length in the first operand. This is time consuming and error prone and should 
be done by the Assembler. And yes I know there are ways around this too but 
again they all rather cumbersome. My suggestion would be to omit/nullify the 
length of the first operand thereby asking the Assembler to use the length of 
the second operand instead. e.g.

   MVC  PRINTLINE(),=C'a nice long constant whose length I dont have to count'
   MVC  0(,R1),=C'or correct because someone else didnt count it correctly'

Kevin Lynch
Senior Software Developer for Implex
William Data Systems

> Date: Wed, 16 May 2012 09:28:05 -0500
> From: [email protected]
> Subject: OT? Assembler "enhancements"?
> To: [email protected]
> 
> I don't really know if this is the place to start a discussion on some things 
> that I, personally, might like to see in HLASM. HLASM is very good. And, 
> until I started doing some z/OS UNIX programming using z/OS UNIX files, I 
> didn't have any problems with it. Now that I'm doing wacky things such as 
> using the vi editor (and vim/gvim on Linux) to edit HLASM source. And as I am 
> getting more UNIXy in my mindset, there are some things that would be helpful 
> to me. And some that just appeal to my foibles.
> 
> 1) Allow for a "free format" option. That is, one which is not column 
> oriented and not "card image" oriented. This would be more like what FLOWASM 
> allows. This would greatly ease keeping HLASM source in z/OS UNIX files and 
> editing them using vi. This is my single biggest wish. FLOWASM is excellent, 
> but I think it would be nice to have as an option in HLASM.
> 
> 2) Use of the hash mark (#) to indicate the beginning of a comment, which 
> extends to the end of the line. Why? OK, a foible of mine. And it's because 
> when my mind is in UNIX mode, this is how most UNIX programs do it. And so I 
> keep typing in # instead of * in column 1 to start a comment. Most irritating 
> of me <grin>. I realize this would be a biggy because # is valid in an 
> identifier. So I don't really expect it to be possible. I tend to avoid @, $, 
> and # in identifiers anyway (do to how they are used in UNIX). But I have 
> embraced using _.
> 
> 3) A "pretty print" utility or option. This would basically use the HLASM 
> scanner to create an "parsed image" of the an entire statement, then use that 
> to make a "pretty print" output which could be written out, say to SYSPUNCH. 
> This would be valid HLASM source which could be compiled. And perhaps use the 
> "free format" option. It would do things such as putting the label, opcode, 
> and first operand on the first output line. The for each positional 
> parameter, put that on a separate output line. Follow these by each keyword 
> parameter on a separate line, sorted by keyword (based on the hex value of 
> the characters in the keyword). I would like "free format" because it means 
> that each parameter (positional or keyword) could be placed on a single 
> separate line instead of possibly continued over multiple lines. I realize 
> that "embedded" comments would be difficult to maintain properly.
> 
> 4) As an option to the "pretty print" and "free format", do proper 
> indentation to support the "structured assembler" macros while "pretty 
> print"ing.
> 
> As you may have guessed, I've been doing some "heavy learning" lately in the 
> z/OS UNIX arena. At present, it is simpler for me to have a UNIX shell going 
> to do my assemblies (via make) while logging on to TSO to use ISPF for 
> editing.
> 
> BTW - the simplest way to tell me this is not of interest is to simply ignore 
> me.
> 
> --
> John McKown
> Systems Engineer IV
> IT
> 
> Administrative Services Group
> 
> HealthMarkets(r)
> 
> 9151 Boulevard 26 * N. Richland Hills * TX 76010
> (817) 255-3225 phone *
> [email protected] * www.HealthMarkets.com
> 
> Confidentiality Notice: This e-mail message may contain confidential or 
> proprietary information. If you are not the intended recipient, please 
> contact the sender by reply e-mail and destroy all copies of the original 
> message. HealthMarkets(r) is the brand name for products underwritten and 
> issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake 
> Life Insurance Company(r), Mid-West National Life Insurance Company of 
> TennesseeSM and The MEGA Life and Health Insurance Company.SM
                                          

Reply via email to