On Mon, 2012-01-02 at 19:08 -0500, John Gilmore wrote:
John McKown wrote:
| One thing which is a bit frustrating is that my macros,
| even if in a UNIX file, must be kept in UPPER case.
Only the NAMES of your macros need be. The text of macro definitions
can be mixed-case.
Yes, I meant the NAMES. I should have been more precise.
Under the covers z/OS UNIX libraries are PDSEs, and PDSE member names
are limited to eight characters---majuscules, numerics and @|#|$---the
first of which cannot be numeric.
I don't know what you mean by z/OS UNIX libraries. Do you mean archive
libraries, as maintained by the ar command? I didn't mean them. I keep
the macros for my UNIX project as regular UNIX files in a UNIX
subdirectory. I believe that HLASM (the as command?) currently
concatenates them to the SYSLIB DD and just uses standard BPAM (and its
support for a UNIX subdirectory as if it were a PDS, kinda, sorta).
I had heard that the deprecated HFS filesystem was based on PDSE code.
But all the filesystems at work are in the currently recommended zFS
filesystems (VSAM Linear) format.
The syntax of aliases for these names, including that of the UNIX
principal alias, is much more relaxed. In a UNIX environment It might
therefore be possible to induce the HLASM to create an eight-character
mangled name from a longer macro name, use it as the member name and
supply the longer name as a principal alias. This, as I'm sure you
know, it what some C compilers do to address the same problem.
I don't have a C license, so I've not looked at how the C compiler on
z/OS works. I am aware that there exists a /usr/include subdirectory
supplied with z/OS which contains a lot of files ending in .h. This is
similar to what I am familiar with on my Linux system. I am also aware
that there are a bunch of PDSes that contains members which I guess are
used for batch C compiles.
John Gilmore, Ashland, MA 01721 - USA
What I would wish for is to have HLASM be able to use UNIX facilities
directly to read UNIX resident code as well as support copy names and
macro names 8 characters for UNIX resident source. And I do realize
that this this unlikely due to lack of need on the part of IBM
internally (little HLASM development any more) and likely resistance by
customers to the cost (cost benefit).
--
John McKown
Maranatha!
