Re: "action" in UK33496

-----Original Message-----
From: IBM Mainframe Discussion List
[mailto:IBM-MAIN@xxxxxxxxxxx] On Behalf Of Paul Gilmartin
Sent: Monday, April 21, 2008 11:15 AM
To: IBM-MAIN@xxxxxxxxxxx
Subject: Re: "action" in UK33496

[snip]


Every well-designed language, application, programming system should
have a way to force an error. IDCAMS has such; HLASM has MNOTE;
zSeries has x'00'. Rexx lacks such; I resort to dividing by zero
or accessing an uninitialized variable to force an error.

Also, every well-designed language should have:

o Comments

A well designed language would not just have comments, but would enforce
comments. Of course, the most excellent language would understand the
comments themselves and that would actually be the code! Nerd-vana.


o A no-op.


[snip]

This more likely happens with new OP codes overloading user-defined
macro names.

As a courtesy, the vendor should partition the name space and commit
to leaving some fraction available for user-defined macros
and promising
that no new OP code or macro will intrude on the space ceded to users.

The component prefix registry could be used for this, and also to
mitigate contention between ISVs. The statement should be that
no new OP code or macro name will ever overlap a registered
component prefix.

-- gil

I do not really care for component prefixes. What about my macros? What
if some vendor duplicates my name?

I would, sort of, like HLASM to implement "namespaces". My idea would be
something along the lines of it working like it does today, with one
addition. Where you can currently place either a macro name (opcode
field), or as part of the parameter (member name) of the COPY, be able
to specify a DD name which is used instead of SYSLIB to resolve the
macro or copy statement. Eg

COPY CALIB:MSG

or
CALIB:MSG 'THIS IS A MESSAGE FROM A CA PRODUCT',other parms

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

.

Relevant Pages

  • Re: [Luxasm-devel] The "Unified Model"
    ... be done using the _current_ design of the macro system and some ... the directives -- I will address what and where momentarily. ... done in the NASM macros I am using to write Luxasm.) ...
    (alt.lang.asm)
  • Re: Difference between a MACRO and a FUNCTION
    ... waste some of the time of every attentive programmer who reads it. ... this macro, I'm likely to waste time convincing myself that the macro ...
    (comp.lang.c)
  • Re: Insert Time Not Updated
    ... But a macro is the way to go ... Re this suggestion, Unlinking the field (Unlink Field, which makes it plain ... Sub InsertTime() ...
    (microsoft.public.mac.office.word)
  • Re: what will be the value of #define
    ... convention for ensuring that multiple inclusions of header files ... #ifndef FRED_H ... then the first inclusion will have the macro "FRED_H" undefined, ...
    (comp.lang.c)
  • Re: Thoughts on refactoring COBOL
    ... You may find the updated version of open source zcobol and z390 coming ... macro assembler source. ... HLASM assembler, C, Java, or Intel MASM using the included zcobol ... Only the HLASM target language is being fully developed ...
    (comp.lang.cobol)