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
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
