On Mon, Mar 23, 2015 at 2:11 PM, Blaicher, Christopher Y. <[email protected]> wrote: > I have not followed all that has gone on before, but I have to defend John E. > a little and make a small suggestion. > > The basic syntax only says you can have a label followed by one or more > blanks followed by an opcode followed by one or more blanks followed by an > optional set of operands followed by one or more blanks followed by optional > comments. If you want to continue a card, put a non-blank in 72 and continue > the data starting in column 16. This is not arcane, except for continuation > situations. Starting continuations in column 16 actually makes sense when > looked at in the context that 16 was where operands normally went and that > the most common thing continued was an operand. >
Well, part of _my_ problem is the brain dead, uh minimalist, vi implementation in which I do not what what column my cursor is in. The vi variant for "real" vi user is vim, which has a "status line" on the bottom which has both the line number within file and cursor position with line (column number) on it. That status line also has the name of the file and a changed indicator. If I had that on z/OS, then I would be cooking with napalm. > Backwards compatibility is important. Having been around since real 5081 > cards were the norm, I can still take a program I wrote back then and > assemble and run it today without changing a single keystroke. The greatest > thing about what started out as OS/360 is the fact that with all the changes, > very little, if any, non-system code has been deprecated. > Me too. I've dropped a number of card trays in my day. And was very happy they were sequenced in 73-80! > Now it would be nice to be able to indicate a new format by using > RECFM=V/VB/VBS and that not allowing for a continuation, but a record as long > as you need. It could also allow for a tab character to be considered a > 'whitespace' or blank if it occurs outside of a quoted string. > Most excellent. > Using consistent column locations for the opcode and operands and comments, > 10, 16 and 35 being the most common, makes for easier reading of a program. > Even given a new format, I would still align my opcodes and operands. Given > long labels, I put them on a separate record and use a DS 0H so my opcodes > and operands still line up. > Perhaps what I really need to do is to implement a FLOWASM driver which can take my source, which FLOWASM makes acceptable to HLASM, and use said driver to reformat my "free form" HLASM into "column oriented" HLASM before distributing it via the CBT. I was looking at that some time ago, but well "my get up and go has got up and went" when I was told that I was definitely losing my job by the end of the year. > Chris Blaicher > Principal Software Engineer, Software Development > Syncsort Incorporated > 50 Tice Boulevard, Woodcliff Lake, NJ 07677 > P: 201-930-8260 | M: 512-627-3803 > E: [email protected] -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown
