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

Reply via email to