HLASM macros in z/OS UNIX subdirectories.
McKown, John
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * 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
Tancer, Jiri
Ward Able, Grant
http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.asma500%2Fasmi102072.htm
Regards - Grant.
Telephone Internal: x1496 London
Telephone External: +44 (0)207 650 1496
Administrative Services Group
HealthMarkets(r)
<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
Steve Comstock
Well, it's a little hokey, and I'm not able to test it right
now, but what about having a series of 'copy' statements at
the front of your program that copy in the macro files?
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
Paul Gilmartin
> Just for learning, and fun (FSVO "fun"), I'm doing some programming in HLASM for z/OS UNIX. In the spirit of things, I'm keeping the source in UNIX subdirectories and using the "make" UNIX command, in an interactive UNIX shell, to control the assembly (using the "as" UNIX command) and linking (using the "ld" UNIX command). I've run into an irritation. I like to keep my UNIX file names in __lower__ case. The source code in my assembler invokes one of my macros. The source is in lower case. I get a "macro not found" error because the assembler UPPER CASES the macro name before looking for the macro. I guess I understand why HLASM does this. But is there __any__ way to have HLASM r6.0 (PTF UK54260) use lower case? Or am I stuck with making my UNIX resident macro names UPPER CASE? I know that I have the -I to search my UNIX subdirectory set correctly because if I make the UNIX file name UPPER CASE, then it assembles cleanly.
>
Right. If HLASM can do it for EXTRNs, why not for macros.
If Binder supports a Mixed/UPPER switch, why not HLASM?
In the interim, a short awk or sed script (I don't know perl)
could create symlinks with HLASM-friendly names.
We've experimented with bilingual C/HLASM copybooks. Some
in production, in fact. In C:
#define MACRO
#include "FOO"
Then in FOO:
MACRO /* assembler code; ignored by C
&L FOO args
*/ C declaration /*
HLASM declaration
*/ C declaration 2 /*
HLASM declaration 2
...
-- gil
Thomas David Rivers
> Just for learning, and fun (FSVO "fun"), I'm doing some programming
> in HLASM for z/OS UNIX. In the spirit of things, I'm keeping the source
> in UNIX subdirectories and using the "make" UNIX command, in an
> interactive UNIX shell, to control the assembly (using the "as" UNIX
> command) and linking (using the "ld" UNIX command). I've run into an
> irritation. I like to keep my UNIX file names in __lower__ case. The
> source code in my assembler invokes one of my macros. The source is
> in lower case. I get a "macro not found" error because the assembler
> UPPER CASES the macro name before looking for the macro. I guess I
> understand why HLASM does this. But is there __any__ way to have HLASM
> r6.0 (PTF UK54260) use lower case? Or am I stuck with making my UNIX
> resident macro names UPPER CASE? I know that I have the -I to search
> my UNIX subdirectory set correctly because if I make the UNIX file
> name UPPER CASE, then it assembles cleanly.
>
> --
> John McKown
> Systems Engineer IV
> IT
<shameful plug>
Well - I don't know of a way in HLASM - but the Dignus assembler
in that environment has a pretty powerful search mechanism that
lets you do precisely that...
You can cause it to use lower or upper-case letters, append
a suffix (e.g. ".mac") or just about anything you'd like.
This works under z/OS UNIX and all the other UNIXes/Linuxes we support.
You can also do cool things like put your maclib members in a ZIP file
and have it look there.
</shameful plug>
Happy Holidays everyone!!!
- Dave Rivers -
--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
McKown, John
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * 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
McKown, John
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * 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
> -----Original Message-----
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Steve Comstock
> Sent: Tuesday, December 20, 2011 9:47 AM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: HLASM macros in z/OS UNIX subdirectories.
>
Paul Gilmartin
> John - will this help?
> http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.asma500%2Fasmi102072.htm
>
Where I read:
CASE
Instructs the assembler to maintain uppercase alphabetic character set
compatibility with earlier assemblers. It restricts language elements
to uppercase alphabetic characters A through Z if they were so restricted
in earlier assemblers.
> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of McKown, John
> Sent: 20 December 2011 15:30
>
> Just for learning, and fun (FSVO "fun"), I'm doing some programming in HLASM for z/OS UNIX.
But beware. It's not well exercised. I've had a few APARS on
things such as 0C4 ABENDs because FREEMAIN wasn't using the same
key as GETMAIN (twice, IIRC -- regressed in a subsequent release)
and nested COPY commands failing to POINT to the right place after
exiting the inner COPY. Mostly DfSMS fault, not HLASM. I originally
discovered some of these problems using a UNIX directory in my Rexx
SYSEXEC concatenation, but that's not supported, but I was able
to reproduce them with HLASM SYSLIB, where they are supported and
were fixed. The PTFs repaired Rexx likewise.
> In the spirit of things, I'm keeping the source in UNIX subdirectories and using the "make" UNIX command, in an interactive UNIX shell, to control the assembly (using the "as" UNIX command) and linking (using the "ld" UNIX command). I've run into an irritation. I like to keep my UNIX file names in __lower__ case. The source code in my assembler invokes one of my macros. The source is in lower case. I get a "macro not found" error because the assembler UPPER CASES the macro name before looking for the macro. I guess I understand why HLASM does this. But is there __any__ way to have HLASM r6.0 (PTF UK54260) use lower case? Or am I stuck with making my UNIX resident macro names UPPER CASE? I know that I have the -I to search my UNIX subdirectory set correctly because if I make the UNIX file name UPPER CASE, then it assembles cleanly.
>
And the "cc" command (I don't know about"as") gratuitously forces the
argument of SYSPARM to upper case, notwithstanding that HLASM tolerates
all argument names and values in mixed case, and when invoked from JCL
accepts SYSPARM (quoted, of course) ASIS. I haven't tried a PMR
on this.
-- gil
McKown, John
for i in *;do j=$(echo $i|tr '[a-z]' '[A-Z]');ln -s $i $j;done
to get "REGS" as a symlink to "regs". What a PITA.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * 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
> -----Original Message-----
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin
> Sent: Tuesday, December 20, 2011 9:47 AM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: HLASM macros in z/OS UNIX subdirectories.
>
McKown, John
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * 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
> -----Original Message-----
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Thomas
> David Rivers
> Sent: Tuesday, December 20, 2011 9:56 AM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: HLASM macros in z/OS UNIX subdirectories.
>
> >
David Bond
>Right. If HLASM can do it for EXTRNs, why not for macros.
>If Binder supports a Mixed/UPPER switch, why not HLASM?
The binder actually supports UNIX files. HLASM uses BPAM. This mess is a
result of z/OS's BPAM support of UNIX files.
David
McKown, John
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of David Bond
> Sent: Tuesday, December 20, 2011 10:11 AM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: HLASM macros in z/OS UNIX subdirectories.
>
So, hopefully, some future version of HLASM will directly support UNIX files. The BPAM support for UNIX seems to be a bit "lacking". I say this because BPAM does support using all possible hex values as a member name, excluding 8x'FF'. SMP/E uses really weird member names successfully. And you can even browse or edit them from ISPF. Hum, since the name in the message is UPPER CASED, perhaps this particular "problem" is due to HLASM after all.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
Paul Gilmartin
>
> <shameful plug>
> Well - I don't know of a way in HLASM - but the Dignus assembler
> in that environment has a pretty powerful search mechanism that
> lets you do precisely that...
>
> You can cause it to use lower or upper-case letters, append
> a suffix (e.g. ".mac") or just about anything you'd like.
>
> This works under z/OS UNIX and all the other UNIXes/Linuxes we support.
>
> You can also do cool things like put your maclib members in a ZIP file
> and have it look there.
> </shameful plug>
>
Dignus in support of z196 opcodes.
Don't know about z390. But the source is available. Haven't
even tried z390 with a concatenation/searchpath of directories.
From the earlier cited:
CASE
Instructs the assembler to maintain uppercase alphabetic character set
compatibility with earlier assemblers. It restricts language elements
to uppercase alphabetic characters A through Z if they were so restricted
in earlier assemblers.
It becomes a question of whether macro names are "language elements".
I'd say, "No." HLASM disagrees with me. The criterion is that
opcodes are enumerated in a Reference Manual; user-defined macro
names are not.
HLASM provides exits for I/O processing. We've used them, exactly
for source/macros in UNIX directories, prior to the availability
of NFS. I had no cause to investigate whether the exit can
perform the OPEN and defer all further processing to HLASM.
-- gil
Paul Gilmartin
I wonder how IBM made POINT work with UNIX files? A more
modern assembler design would eschew NOTE/POINT and use
multiple DCBs for nested COPYs.
I had a performance APAR where I reported that Binder was
orders of magnitude slower writing SYSPRINT to a UNIX file
than piping to "cat" writing to a UNIX file. IBM's
resolution was to modify Binder to OPEN the SYSPRINT path
and use BSAM/QSAM. Apparently Binder had re-invented
the flat tire. (In fairness, Binder supported UNIX files
before the BSAM/QSAM support was available for such.)
(Veering off-topic: when I use the DD: form of local files
with FTP, FTP ignores overriding attributes on the DD
statement and gets the information elsewhere, often from
the DSCB. Again, it fails to employ BSAM/QSAM where I
believe it should.)
-- gil
Paul Gilmartin
>>
>> The binder actually supports UNIX files. HLASM uses BPAM.
>> This mess is a
>> result of z/OS's BPAM support of UNIX files.
>
>
and report Member not Found?
Does SMP/E still do that? I thought it was historical behavior
and SMP/E now uses VSAM.
Can the programmer use weird names in SMP/E MCS/Commands, or are
they only used when generated by SMP/E? I know that the CSECT
option on the ++MOD MCS allows anything except ' ', ',', and ')'.
(IIRC) Itself restrictive because I believe Binder allows the
latter two.
-- gil
Paul Gilmartin
>
> So, hopefully, some future version of HLASM will directly support UNIX files. The BPAM support for UNIX seems to be a bit "lacking". I say this because BPAM does support using all possible hex values as a member name, excluding 8x'FF'. SMP/E uses really weird member names successfully. And you can even browse or edit them from ISPF. Hum, since the name in the message is UPPER CASED, perhaps this particular "problem" is due to HLASM after all.
>
OPTABLE to exploit some new instructions. But it's highly likely that
IBM's new OPTABLE will contain some opcodes, whether we use them
or not, that will collide with some of our macro names.
IBM has not nicely partitioned the macro name space, IBM/ISV/end user
to avoid collisions. At one time, there was a rule of thumb that
opcodes were short, and if ISVs and customers used only long macro
names, they were pretty safe. That has fallen by the wayside.
Opportunity knocks. What if IBM were to commit to using only upper
case characters in opcode and macro names, leaving mixed case
names the domain of ISVs and customers.
Didn't I hear that IBM had to arbitrate a collision between one of
its own macro names and one of its own opcodes lately?
-- gil
John Gilmore
that any will be defined soon. Macro definitions that have such
'long' names are therefore unlikely to conflict with opcode mnemonics.
As I suppose most of you know such construction as
|&macname setc 'gubbins' --character value of macro name
| &macname . . .
|
or
|&macnames(1) setc 'MCGUFFIN','MCGOFFIN','GUBBINS'
| . . .
| &macnames(&i) . . . --character value of macro
name
is already supported by the HLASM. The value of a character set
symbol may appear in the operation field where a macro's name usually
appears.
This suggests that without much trouble the assembler could be induced
to support such an idiom as
|&macname setc 'gubbins' --character value of macro name
|&xmacname setc C2X(&macname) --its hexadecimal value using available BIF
| &xmacname . . .
This could be routinized, even encapsulated, readily to make it less tedious.
It is my uninformed guess that it would also be easy to implement
since BPAM would not find it problematic, but John Ehrman or one of
the Perth Laboratory people who monitor this list may see
insurmountable difficulties in doing so.
--
John Gilmore, Ashland, MA 01721 - USA
Robert A. Rosenberg
macros in z/OS UNIX subdirectories.:
>Well, it's a little hokey, and I'm not able to test it right
>now, but what about having a series of 'copy' statements at
>the front of your program that copy in the macro files?
That could work for outer macros (ie: Thus that you call directly)
but would not solve the issue of inner macros (ie: Those your outer
macros call). The inner macros would need to also be in the copy
list. You can do an iterative process where you create the copy
statements, try the assembly, look at the list of missing macros, add
them as copys, and try again until there are no more missing macro
errors. It might be simpler to do a PRINT OFF, COPY statements, and
PRINT ON with one COPY for each macro in your directory. This might
cause the Assembler to choke on all the macros however.
John Ehrman
PDS members had upper-case names, and you had to "play games" (such as
doing your own BLDL and STOW) to get anything different.
If you believe mixed-case support is worth pursuing, submit a request
through your local IBM rep.
(I used to have fun creating member names with a blank in the middle, so
that other programs would see only the pre-blank characters.)
John Ehrman
John McKown
> The reason HLASM upper-cases macro names is historic: in the early days all
> PDS members had upper-case names, and you had to "play games" (such as
> doing your own BLDL and STOW) to get anything different.
>
> If you believe mixed-case support is worth pursuing, submit a request
> through your local IBM rep.
>
> (I used to have fun creating member names with a blank in the middle, so
> that other programs would see only the pre-blank characters.)
>
> John Ehrman
>
I couldn't convince a person dying of thirst in the desert to take a
drink of water. Try to convince IBM of something like this? No. I will
simply "go with the flow" and use UPPER case via symlinks to the lower
case name.
--
John McKown
Maranatha! <><
Tony Harminc
> Didn't I hear that IBM had to arbitrate a collision between one of
> its own macro names and one of its own opcodes lately?
I don't know about lately, but 25 or so years ago they broke use of
the then state-of-the-art ASMH on VM/SP by adding a TRACE instruction
to the XA architecture, when VM already had a widely used TRACE macro.
IBM's response to complaints was to point out that Asm XF was the only
supported assembler for building VM, and reject the APAR.
Tony H.
Bob Fake
Thank you again for contacting InfoSec and have a Merry Christmas, Happy Holiday and best wishes for a great 2012.
Bob Fake
703-825-1202
www.infosecinc.com
Paul Gilmartin
> Just for learning, and fun (FSVO "fun"), I'm doing some programming in HLASM for z/OS UNIX. In the spirit of things, I'm keeping the source in UNIX subdirectories and using the "make" UNIX command, in an interactive UNIX shell, to control the assembly (using the "as" UNIX command) and linking (using the "ld" UNIX command).
>
An off-list discussion has prompted a question: How does BPAM
implement NOTE and POINT for UNIX files? If we create copybook
members with vi, emacs, nedit, jedit, ... and allocate SYSLIB
with FILEDATA=TEXT,RECFM=FB,LRECL=80,PATH=..., the (emulated)
BPAM will pad lines with 0x40 to 80 byte records. Then a nested
COPY causes a NOTE; copies in the nested member and POINTs back
to the previous position. I'd expect POINT to use fseek()
internally. But how does it calculate the fseek() argument,
not knowing how many padding bytes were added previously?
Or does BPAM keep a journal?
Years ago I had a PMR on failure of this operation. IBM fixed
it. I have no idea how.
John and I would never tolerate being required to pad lines in
all our UNIX files to 79 characters plus <NL>.
-- gil
McKown, John
> From: IBM Mainframe Assembler List
> Sent: Thursday, December 22, 2011 9:08 AM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: HLASM macros in z/OS UNIX subdirectories.
>
> On Dec 20, 2011, at 08:29, McKown, John wrote:
>
> An off-list discussion has prompted a question: How does BPAM
> implement NOTE and POINT for UNIX files? If we create copybook
> members with vi, emacs, nedit, jedit, ... and allocate SYSLIB
> with FILEDATA=TEXT,RECFM=FB,LRECL=80,PATH=..., the (emulated)
> BPAM will pad lines with 0x40 to 80 byte records. Then a nested
> COPY causes a NOTE; copies in the nested member and POINTs back
> to the previous position. I'd expect POINT to use fseek()
> internally. But how does it calculate the fseek() argument,
> not knowing how many padding bytes were added previously?
> Or does BPAM keep a journal?
>
> Years ago I had a PMR on failure of this operation. IBM fixed
> it. I have no idea how.
>
> John and I would never tolerate being required to pad lines in
> all our UNIX files to 79 characters plus <NL>.
>
> -- gil
Why wouldn't it just use ftell() to record the actual position in the UNIX file, independant of its reformatting of the data placed into the user's buffer? Then fseek() back to that.
Paul Gilmartin
> <snip>
>> An off-list discussion has prompted a question: How does BPAM
>> implement NOTE and POINT for UNIX files? If we create copybook
>> members with vi, emacs, nedit, jedit, ... and allocate SYSLIB
>> with FILEDATA=TEXT,RECFM=FB,LRECL=80,PATH=..., the (emulated)
>> BPAM will pad lines with 0x40 to 80 byte records. Then a nested
>> COPY causes a NOTE; copies in the nested member and POINTs back
>> to the previous position. I'd expect POINT to use fseek()
>> internally. But how does it calculate the fseek() argument,
>> not knowing how many padding bytes were added previously?
>> Or does BPAM keep a journal?
>
>
o the catenand number
o TTR within the catenand, which serves to identify both
the member and the block.
For a UNIX directory, it would need to identify:
o the catenand number
o the member within the directory
o the relative byte address within that member.
Is a NOTE token sufficiently large to contain all
this information? Particularly given that a concurrent
process may be adding or deleting members from the same
directory.
-- gil