John,
Since you are discussing sanity, or rather the lack thereof, let me add in
my two cents --
In general, I like the proposal.
In respect to the COPY statement, I would recommend the following format --
COPY
[:name-space]:]member
I would also add an extension for OPSYN --
operation-name-1 OPSYN
[:[name-space]:]operation-name-2
And for z/VSE, which uses LIBDEFs rather than DD names, I would add
extensions for the definitions of sublibraries and namespace search chains
--
sublib-ref-name SLDEF
[lib-name.sublib-name[.suffix]]
In this extension --
The assembler directive, "SLDEF", is just an
example. An appropriate assembler directive would have to be determined.
"sublib-ref-name" is a 1-8-character name which will
be used to reference a particular z/VSE sublibrary.
"lib-name" is a 1-7-character library DLBL
reference.
"sublib-name" is a 1-8-character sublibrary name.
"member-suffix" is a 1-8-character member suffix
(default is "A").
If no operand is provided, the "sublib-ref-name"
would be deleted, and any namespace search chain referencing that sublibrary
reference would be invalidated.
namespace-name NMSPC [sublib-ref-name-1[,...]]
In this extension --
The assembler directive, "NMSPC", is just an
example. An appropriate assembler directive would have to be determined.
"namespace-name" is a 1-8-character name which will
be used to reference a list of sublibraries to be searched for a particular
macro.
"sublib-ref-name" is a previously defined
1-8-character sublibrary reference.
Within the namespace, the sublibraries will be
searched in the order listed.
If no operands are provided, the "namespace-name"
would be deleted.
I would also recommend the creation of a new &SYSxxxx variable which would
permit a macro coder to determine the namespace used to invoke the macro.
I would also recommend the creation of new &SYSxxxx functions which would
permit macro coder to example sublibrary and namespace definitions.
I will leave it to the z/OS and z/VM gurus to make suggestions as to how
these extensions could be implemented on their respective platforms.
Significant changes will be required in all of the various user exits in
support of these extensions.
John P. Baker
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]]
On Behalf Of McKown, John
Sent: Wednesday, October 27, 2010 2:08 PM
To: [email protected]
Subject: Thoughts on "enhancements" to HLASM or other z assembler
OK, these are just my insanity. Blame them on the meds <grin>
===
David Bond gave an excellent description of the OPCODE table and how it
works for builtin opcodes, pseudo-ops, and macros. So, what would it take to
compatibly extend this to what I will call "namespaces". My thought was to
change the opcode parsing such that a currently invalid first character
(such as a colon) in the opcode field could introduce a "namespace". The
default namespace would be the current opcode. The value after the colon
would be a "namespace". The "namespace" could be null (omitted) for the
current OPCODE table namespace. Otherwise, the "namespace" is the DD
concatenation used to search for a MACRO. For the default "namespace", the
DD to be searched would remain SYSLIB.
Example:
NORMAL LA R1,MYVAR
NORMAL ::LA R1,MYVAR does the same as above because the :: uses the
default namespace
ABNORM :SYSLIB:LA R1,MYVAR Forces the assembler to look for a MACRO
called LA in the SYSLIB DD concatenation
ABNORM2 :MYLIB:OPEN PARMS... Ah! I have my MACRO which I want to call
OPEN. Use the DD MYLIB instead of SYSLIB
NORMAL OPEN (DCB,(INPUT) use the normal DD of SYSLIB for this OPEN,
with no conflict to my defination.
Reason: This totally avoids collisions between new OPCODES, and different
MACROs from different vendors which happen to have the same name, but I need
in my program. Note for non-z/OS based assemblers, the DD statement would
instead be an environment variable using standard subdirectories and
delimiters. For example:
export MYLIB='~/projects/proj1:~/projects/proj2'
===
Extend the COPY operation to use the same "namespaces" as above. so that I
can specify a DD from which to copy the member.
Reason: Same as above.
===
HLASM source format changes. This one most likely can be implemented via
HLASM's SOURCE exit. But I'll mention it just so that people can make
comments as to their thoughts on whether I've gone over to the dark side (or
over the edge).
Card image is so retro! Why, especially on z/Linux (if this applies to that
version of HLASM), when I can keep my HLASM source in UNIX files (locally,
NFS mounted, or on a Windows share), am I still stuck with LRECL=80 and
RECFM=F? Now, I know that so long as my logical records are < 80 bytes, I
can use the DCB and PATH to make my UNIX files look like FB/80. But for long
lines, I still need that non-blank in column "n" (default 72). And exactly
"n" (default 16) blanks on the next record. What I would like is to be more
like the C compiler. If the last non-blank character on a logical line is a
back slash (\), then ignore any trailing blanks on that line and assume the
next logical line is a continuation of this line. All leading blanks on the
next line are ignored. If the next line starts with a \, it too is ignored.
This is so that a continuation line can be part of a literal and have a
blank at the start. Of course if the continuation is in a literal and the
character requ!
ires a \ as the next literal character, just code two \\s in a row.
example:
NEW CLC SOMELONG,=CL100'THIS IS A REALLY,\
\ REALLY LONG \
LINE'
The literal is "THIS IS A REALLY, REALLY LONG LINE".
Macros and COPY code also need to be able to work this way too. So I guess
an equivalent LIBRARY exit is required as well.
===
Is any of this even a possible interest or concern to anybody else? Or am I
becoming to UNIXy?
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell [email protected] *
www.HealthMarkets.com
