Macro Processors

[John Ehrman]

Charles Mills noted... 




> Date: Sat, 9 Dec 2017 17:58:15 -0800 
> From: Charles Mills <charl...@mcn.org> 




> PL/I has a very powerful "macro" (preprocessor, I think they call it) 
> facility. I don't know it well at all, but in my impression it is more 
> powerful than either assembler or C macros. 




I agree that PL/I's macro preprocessor is indeed powerful; but it and 

all other macro facilities I know of lack a key feature of HLASM's 

conditional assembly and macro facility: an intimate interaction 

between the base language and the macro language. While the 

HLASM facility is a bit primitive in some ways, it can still do things 

that no other can. 




A simple example is that you can access attributes of base-language 

symbols; another is that you can assign your own attributes to symbols 

and use those attributes to generate tailored instruction sequences. 

Another is that your macros can invoke external functions to extend 

its arithmetic and string-handling capabilities, as well as to access 

the environment in which the assembler is executing. 




I've given a macro tutorial several times at SHARE (a fast 2 hours) 

that has some case studies with examples of the power of this base- 

and macro-language interaction HLASM's conditional assembly and 

macro facilities. If you have access to SHARE proceedings you can 

find it there. 




John Ehrman 

Address of a Literal

[John Ehrman]

A literal is implicitly a symbolic address and a constant-generation request; 
nesting those functions in other expressions was considered a bit too much 
extra work for ASMH, from which HLASM was derived. And there were no strong 
requests for forms such as A(=X'zzz') during the first six HLASM releases. 

As I remember, the problem with adcons containing literals is that they can 
lead to recursions such as A(=A(...)) and the like. 

John Ehrman 

HLASM "Anomaly"

[John Ehrman]

I think I have a clearer picture now than I had previously: for instructions, 
the operand parser evaluates expressions, while for DC/DS operands, the operand 
parser evaluates duplication factors. For example: 

LHI 0,2X'FF' is invalid because the operand is not an expression 
LHI 0.2*X'FF' is valid, and the operand has value X'1FE' 

DC 2X'FF' generates X'' 
DC 2*X'FF' is invalid because the operand is not a duplication factor 

So I see no language "anomaly", but perhaps a lack of detailed explanation in 
the Language Reference. 

John Ehrman 

Re: ASSEMBLER-LIST Digest - 24 Feb 2017 to 25 Feb 2017 (#2017-14)

[John Ehrman]

Well, maybe not. I was laid off ("retired") by IBM last June, and managed to 
get back to this list only a few days ago. I'll try to keep active if I haven't 
forgotten too much. 
John Ehrman 
- Original Message -

From: "ASSEMBLER-LIST automatic digest system" <lists...@listserv.uga.edu> 
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 
Sent: Saturday, February 25, 2017 9:00:04 PM 
Subject: ASSEMBLER-LIST Digest - 24 Feb 2017 to 25 Feb 2017 (#2017-14) 

Date: Sat, 25 Feb 2017 10:05:57 -0500 
From: Steve Smith <sasd...@gmail.com> 
Subject: Re: HLASM anomaly 

Have you not seen the many prior discussions of this excruciating topic? 

Re HLASM Anomaly

[John Ehrman]

Another reason not to allow DC-type operands in immediate operands: consider 
AHI 0,(N)X'F' 
The Assembler can't tell that the instruction is indeed 4 bytes long. 
I suppose it could do some acrobatics, but the cost vs. value seems excessive. 
John 

Re Immediate operands

[John Ehrman]

Immediate operands don't support duplication factors because they're not 
immediate. Consider all the places in statements where a numeric value can 
occur -- constructs like BALR 2FL.41'7',3BL.4'101' -- I guess we never thought 
of documenting that restriction because we never thought someone would try it! 
John Ehrman 
-- 
Date: Wed, 22 Feb 2017 16:18:38 -0500 
From: Melvyn Maltz <zarf77...@blueyonder.co.uk> 
Subject: HLASM anomaly 

Immediate operands won't accept a duplication factor...why not ? 
Can't find a reason in the HLASM manual 

Try these... 
CFI R1,4X'FF' 
CFI R1,X'' 
CFI R1,-1 
AHI R1,2X'FF' 
AHI R1,X'' 
AHI R1,-1 

Melvyn Maltz 

Re: Structured Programming Macros

[John Ehrman]

Rob Van der Heij noted:

>> Is the request you mentioned a SHARE requirement or an IBM RFE?  In any
>> case, can you point us where to vote on that request?

>John referred to this RFE, I think

The original posting was by Sharuff Morsa in Hursley, which gave this link 
and request:

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=88038 

Please read the RFE and let us know your views

My Assembler Text

[John Ehrman]

Some materials that may be useful to teachers of IBM mainframe Assembler 
Language are now available on the Marist College web site, along with the 
text itself.

The two items are PDFs with  (1) lecture slides for Chapters 1-8 (sorry, I 
ran out of time before I could do the rest), and (2) pages with 
mini-slides (also ch. 1-8) followed by some notes lines where a lecturer 
can jot notes for use when projecting the full-size slides.

They are available at 
http://idcp.marist.edu/enterprisesystemseducation/assemblerlanguageresources-1.html
 


and if you want to access them by a different route, try 
http://idcp.marist.edu and then hover over "enterprise systems education" 
to get a drop down where you can hover over "technical resources" which 
will display another drop down where you can click on "assembler 
resources" - that will take you to the URL page above. 

Many thanks to Angelo Corridori of Marist College for hosting the 
materials, and to the many readers of these forums for their helpful and 
generous comments.

As I noted earlier, I'll be retiring from IBM at the end of May, so if you 
have any comments or suggestions, please send them to me at  
johnehrm...@gmail.com  .

I hope to do some consulting, so if you know of anyone who can use help 
with Assembler Language training, consulting, or advice, please let me 
know.  Thanks.

Regards... John 

Re: ASM0A43E Previously Defined Symbol

[John Ehrman]

Two comments:

(1) Mike La Martina wrote 

>One would think so but HLASM does not have scoped namespaces.
>My suggestions for such have been summarily dismissed.

Your suggestion wasn't "summarily dismissed" -- it's just that it would 
require substantial internal modifications to the assembler.  We don't 
(and didn't) have sufficient resources to do it.  Perhaps we didn't reply 
tactfullly.

(2) Michael Butz asked

>If I have to two dsects with the same label and I qaulify the usage of
the dsect with a label on the using shouldn't that do away with above 
error message

In your example, the DSects had different names, but each contained a 
field with the same name.  Currently, HLASM can support only a single 
instance of an internal symbol, so using the same symbol in two different 
DSects won't work.  Sorry!

Regards... John 

Re: My assembler text v2.00

[John Ehrman]

Nope!  I'm hoping I can find things to keep mind and body active.  (Two of 
the reasons I'm hoping we can get OKs to do the A.U. in San Jose.)  Also 
looking for occasional consulting gigs.

We do have some travels planned: Carmel Bach Festival last week of July, 
and a "remembering D-Day tour to England and France in early Sept.  So it 
won't be total inertia.

Regards... John 
-
555 Bailey Ave, San Jose CA 95141 USA
+1-408-463-3543 (fax -3873) TIE 543-
ehr...@us.ibm.com; VMID = EHRMAN at STLVM27



From:   Michael Stack 
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Date:   04/14/2016 11:53 AM
Subject:Re: My assembler text v2.00
Sent by:IBM Mainframe Assembler List 




And is Teneke prepared to have you home all day, day after day, week after 
week, ...?? :-)

Mike

At 06:42 PM 4/13/2016, you wrote:
>...
>
>I'll be retiring from IBM at the end of May, ... .
>
>...
>Regards... John 
>-
>555 Bailey Ave, San Jose CA 95141 USA
>+1-408-463-3543  ehr...@us.ibm.com

My assembler text v2.00

[John Ehrman]

The second edition of my Assembler Language textbook is available for 
download at

http://idcp.marist.edu/enterprisesystemseducation/assemblerlanguageresources-1.html
 


The text is a PDF file (it's big: 1346 pages).  The simple conversion and 
I/O macros decscribed in Appendix B are also available there.

I'll be retiring from IBM at the end of May, so if you have any comments 
or suggestions, please send them to me at  johnehrm...@gmail.com  .

Since the text was created on z/VM using IBM's BookMaster, I doubt I'll be 
able to create any further versions after retiring.  I may, however, be 
able to provde occasional supplements and errata through the Marist 
College web site.  (I'd like to provide a second text describing the 
Conditional Assembly and Macro language, but that will depend on time, 
energy, and need.)

I plan to be available for consulting on Assembler Language topics like 
education, modernization, and simplification.

Regards... John 
-
555 Bailey Ave, San Jose CA 95141 USA
+1-408-463-3543  ehr...@us.ibm.com

Re: Generating warning for AL2 expression truncation?

[John Ehrman]

Paul Gilmartin suggested...

>Given that the hardware now supports unsigned halfwords, perhaps
HLASM should accommodate.  Perhaps HU'65535' or YU(65535). 

Unsigned integer values are supported by HLASM,, but the syntax is 
slightly different:

DC  H'U65535'

John Ehrman

Re: Return code 8 from assembler no messages

[John Ehrman]

Michael Butz wrote:

>I am sorry i had multiple definitions of IBM 
>Mapping macros IHAPSA IHAASCB

>Wonder why it didn't flag it as ** previously defined 

It should; otherwise there's no way to locate the problem.

Re: Use of LQ results in ASMA080E?!

[John Ehrman]

Lizette Koehler asked...

>Would it make more sense to change 0CL512 to 0LQ32  ?

>Does the 0CL512 place it on a quad word boundary?

C-type constants are always aligned on the next available byte, no matter 
what the value of the Length attribute is.

Regards... John Ehrman

Re: Use of LQ results in ASMA080E?!

[John Ehrman]

Peter Farley noted:

>The disadvantage of option SECTALGN(16) when assembling to old-fashioned 
OBJECT format (as opposed to GOFF) is that you get an RC=4 warning from 
the assembly, even if everything works as intended.  This makes it 
unusable in source maintenance systems where RC=0 is the only allowed 
status.

The old OBJECT format has been extended to handle quad-aligned sections, 
named and private, commons, and external dummy sections. The ESD listing 
would show, for example, SQ instead of SD for a section definition.

Which RC=4 diagnostic do you get? ASMA216W? You can suppress any 
warning-level diagnostic with the SUPRWARN(nnn) option.  Whenever you have 
a warning diagnostic that you know won't impact your intended results, you 
can use SUPRWARN to get a clean RC=0 assembly.

Appendix B of the HLASM Programmer's Guide needs updating for the 
quad-alignment stuff; I'll notify the HLASM team.

Regards... John Ehrman

LOCTR and Lookahead (was: Use of LQ results...)

[John Ehrman]

On 12/29/15, Paul Gilmartin posted one of his favorites: 
 
 000 2 1 LOC1 CSECT 
 000 2 2 LOC2 LOCTR 
 003 LOC2CDS0C 
 004 LOC2HDSH 
 000 2 5 LOC1 LOCTR 
 006  DS(LOC2H-LOC2C)C 
 ** ASMA080E Statement is unresolvable
 007  DS0H 
   8  END 
 
and commented first: 
 
 "It's ironic that every expression depends only on symbols which appear 
 earlier in the source, but may be unresolvable." 
 
This is because a LOCTR group is a set of statements to which values are 
not assigned until the complete sequence of LOCTRs and CSECT statements 
have been processed -- effectively, they are "suspended" with unknown 
values at the time statement 6 is encountered.  In this specific case, 
it's not known yet whether the symbol LOC2H will require a padding byte to 
 
follow the LOC2C symbol. 
 
He then commented: 
 
"I wonder whether HLASM's lookahead is documented sufficiently completely 
that a determined programmer with the Reference can decide the correctness 
 
of any program without performing a test?" 

First, the problen in the little program example above has nothing to do 
with lookahead mode, which is specific to conditional assembly. When the 
attributes of a symbol are required in a conditional assembly expression,
and the symbol is unknown, the assembler makes a forward scan over the 
SYSIN file searching for a first occurrence of the symbol. It doesn't 
matter whether or not that occurrence will eventually appear in the final
assembled version of the program. 
 
Second, a "determined" programmer can indeed decide on the correctness of
a such program; but it's much easier to let HLASM do the work for you. 
 
I hope this helps clarify both situations. 
Regards... John Ehrman

Re: External Dictionary

[John Ehrman]

Michel Butz said:

I am looking in 2.2 HLASM guide

Says there are 9 types of symbols 
SD,ED,LD,ER,PC,PR,CM,XD,WX

Can some one give an example say what a ER is 
Is that a CSECT or ENTRY thanks 

ER = External Reference; CSECT generates SD (Section Definition), ENTRY 
generates LD (Label Definition).

ER is created from either an EXTRN statement, or from the operand of a 
V-type address constant.

John Ehrman

Re: Assembler exercise

[John Ehrman]

Bob Netzlof wrote in response to a problem I posed:

  Suppose the desired length is to be the value of symbol T

  T EQU (F+1)*(256+A*(1-L)*65280)

Very elegant! (Much better than my solution.)

Regards... John Ehrman

Assembler exercise

[John Ehrman]

For those needing something to think about

In the description of the TRTE and TRTRE instructions in the POP, there's 
a table giving the expected length of the function-code table for various 
combinations of the three bits named A, F, and L in the M3 mask field. 
Your exercise:

Suppose the three symbols A, F, and L in the M3 mask have been defined as 
absolute symbols with values 0 or 1. 
Suppose also that you must reserve space for a function-code table with 
size depending on the values of A, F, and L, as illustrated
in the POP table. Write an EQU statement defining a symbol TL that will 
contain the length of the reserved area for the table, for all
combinations of values of A, F, and L.

As Tony Harminc says, Have fun... (it can be done).

Regards... John 
-
555 Bailey Ave, San Jose CA 95141 USA
+1-408-463-3543 (fax -3873) TIE 543-
ehr...@us.ibm.com; VMID = EHRMAN at STLVM27

Re: Debuggers

[John Ehrman]

Richard Kuebbing asked

(start) What is the relationship between ASMIDF and IBM's Debug Tool? The 
latter has been problematic dealing with HLASM batch.
(end)

Debug Tool uses similar (and improved) techniques involving VTAM for batch 
debugging.  The reference material is in the Debug Tool User's Guide, 
Chapter 15, and can be accessed at 
http://publibfp.dhe.ibm.com/epubs/pdf/eqaeus03.pdf .

If you have specific requirements for better HLASM debugging support in 
Debug Tool, please submit them through the standard RFE process (we can 
track them better that way  than suggestions made via e-mail or posted on 
the Assembler-List).  But we do encourage discussion on the list!

John Ehrman

Re: Debuggers

[John Ehrman]

Peter Farley noted about ASMIDF (in part):

(Start)
The last time I used it, there was also no capability to directly debug an 
executing batch job like z/XDC and other HLL language debuggers provide.
(End)

More recent versions of ASMIDF do support debugging of batch jobs.

Regards... John

Re: Debuggers

[John Ehrman]

Have any of the responders to the original query used ASMIDF, the debugger 
in the High Level Assembler Toolkit Feature? It's tailored specifically 
for assembler applications.

John Ehrman

Re: Lower case csect/entry names

[John Ehrman]

I just completed an assembler program that will be linked with a c 
program.  The objective of the assembler program is to perform 
SRB/zIIP-enabled socket i/o for the c program.  I would like the csect and 
entry names in the assembler program to include lower case letters (to 
match c conventions).  However, I can’t seem to find a combination of 
assembler options to cause it to create an object module that has lower 
case csect/entry names.  Is this possible?

Use the ALIAS statement.

John Ehrman

Re: Option to Prevent Data Loss Due to Truncation of Nominal Value

[John Ehrman]

Much of this discussion seems to illustrate a risk in using character 
literals: it's difficult to refer explicitly to their length attribute. 
One could write

 MVC   Target(L'=C'very long string'),=C'very long string')

hoping you made the two instances identical.  It seems preferable to me to 
define the literal as a character constant:

LS   DCC'very long string'

and then use its length attribute:

 MVC   Target(L'LS),LS

John Ehrman

Re: Assembler Syntax - was (Regular Expressions followup)

[John Ehrman]

Gord Tomlin observed:

It would be nice to be able to indicate a new format, but not by tying 
the format to an attribute of the data set containing the source. For 
one thing, I should be free to keep source in VB data sets and still use 
the existing format. Much better to have a HLASM option to indicate the 
new format.


What you're suggesting seems very much like what the HLASM input exit 
ASMAXINV does: it re-formats the input into FB80-like records.  (Have you 
tried it?)

John Ehrman

Re: Assembler Quiz

[John Ehrman]

Steve Smith asked for the answer to my quiz question of March 23:

 While we're having fun: under what circumstances is the character 
sequence

 (4)(3)(2)(1)

 legal as part of a machine instruction operand, not part of a quoted
 string, not part of a macro operand, and not part of a SETC statement?

And no, it's not an April-Fool question. 
Here's the answer:
USING  *,12
V(4)   SETC   'L'
LA 0,=AV(4)(3)(2)(1)
END

Try assembling it!  (And no, it wasn't my idea originally.)

Regards... John 

Re: HLASM operand order vs. instruction operand order

[John Ehrman]

Peter Farley asked about why the mixed operand order among (1) The PoP, 
(2) HLASM, and (3) generated instructions.

I'm afraid I don't know, but I suspect it's due to (a) time -- the basic 
architecture is over 50 years old, and (b) the great number of processor 
architects who have designed instructions over that time.  (As my 
grandmother said, It just growed that way.)

I learned recently that STM was not included in the initial instruction 
set, but was added closer to System/360 availability.

As Peter said, maybe others may have insight as well.

John Ehrman

Assembler Quiz

[John Ehrman]

While we're having fun: under what circumstances is the character sequence

   (4)(3)(2)(1)

legal as part of a machine instruction operand, not part of a quoted 
string, not part of a macro operand, and not part of a SETC statement?

Regards... John 

Re: (Regular Expressions followup)

[John Ehrman]

Paul Gilmartin noted...
 IMO, HLASM syntax is the most god-awful piece of clap-trap garbage I 
have
 ever laid my eyes on.  Well, perhaps a close second to JCL.

HLASM's syntax is a direct descendant of the assembler languages for a 
great variety of earlier systems, including the IBM 650, 704, 709(x), 
System/360 etc.  The one novelty in the System/360 assembler language was 
the introduction of a separate, distinct class of variable symbols; 
previous assemblers used ordinary symbols as macro variable symbols.  At 
the time the 360 was being developed, there were no low-level high-level 
languages (PL/S and C came years later); what else was available for 
building systems?  And you'd be truly repelled by the language used on the 
early IAS machines; by comparison, HLASM's is a model of simplicity and 
clarity.

I'm not defending historical clap-trap, but perhaps we're living too close 
to the present?

John Ehrman

Re: HLASM Syntax (was (Regular Expressions followup))

[John Ehrman]

John McKown would like...

The only enhancement that I, personally, would like would be for free
format input into HLASM with _no_ line limits. Mainly because I keep
my HLASM source in a UNIX file and, depending on things, I use the
as UNIX command to assemble it. I'm a bit of a UNIX partisan for
interactives. Being forced to use column alignment when I use a
non-ISPF editor is a royal bother. Hum, it would also be nice if the
tab character were a white space character outside of literals.

HLASM used to ship an input exit (ASMAXINV)  that accepts variable-length 
input records.  Check the Programmer's Guide.

Making the tab character a white space should be easy, but might require 
an option of some sort.

John Ehrman

Re: (My) John Ehrman Assembler Book

[John Ehrman]

Richard Lawrence posted: 
The long awaited John Ehrman Assembler book as available at the 
Marist College web site:


http://idcp.marist.edu/enterprisesystemseducation/Assembler%20Language%20Programming%20for%20IBM%20z%20System%20Servers.pdf

I appreciate the many kind comments posted on these discussion lists.

Please note that some fixes will be in the next update:
(1) The fragmentary index after the preface/introduction will be removed.
(2) The solutions for sections 25 and 26 will be restored.
(3) Various typographic errors will be fixed.
(4) Some minor text reorganizations.

Rather than adding change bars, I plan to add an Updates section 
somewhere at the front or back of the text explaining differences from 
version to version.

After those are finished:
(n) I'm currently preparing some lecturer materials like presentation 
slides.
(n+1) A major item will be to add hyperlinks for contents and 
cross-references.
(n+2) I apologize, Lizette, but I doubt I'll add another 1200 pages any 
time soon.

John Ehrman (ehr...@us.ibm.com)

Advanced Assembler Language etc.

[John Ehrman]

Tony Thigpen, Joey Capps, Rich Smrcina, and others have asked:
Did you ever finish the text book?

Yes, it's done (or at least, I've stopped adding to it) (for now). 

I've gotten permission to make it available, and am working on a 
convenient distribution mechanism.  I'm hoping you'll be able to download 
it in a couple of weeks; when it's set up I expect to post a note on this 
list and on IBM-MAIN with the details.

Re: 8 character mnemonics

[John Ehrman]

Paul Gilmartin asked...
But are new mnemonics vetted against all member names in all maclibs of 
all IBM products? (Do significant ISVs count?)

That was indeed done many moons ago, but the number of products with 
private macro libraries grew far beyond the capabilities of the 
vetters so it's not done any longer.

John Ehrman

Re: 8 character mnemonics

[John Ehrman]

Dave Cole noted...
 Correct me if I'm wrong (John Ehrman),
but I thought that IBM once upon a time,
way back when they started to create mnemonics longer than 5 characters...

I thought they said
their new limit was going to be seven characters.
Well... VSTRCZFS.


I don't remember any such claim, but I agree that the potential for 
collisions between mnemonics and macro names has increased.  That's why 
HLASM added the operation-code suffixes (tags) :ASM and :MAC so you can 
explicitly specify which mnemonic resolution you want.

John Ehrman

Re: 8 character mnemonics

[John Ehrman]

Dave Cole noted again...
But it does make me wonder if they might eventually go to 9 or 
longer...

I think HLASM has supported operation field entries longer than 8 
characters for a long time, but resolution was possible only to source 
macros. (No, I haven't tried it.)

John Ehrman

John Kalinich

[John Ehrman]

John, can you send your e-mail ID to me? It's about some material you 
reviewed for me. (Apologies to everyone else.)

ehr...@us.ibm.com

Re: HLASM support for z13

[John Ehrman]

A new Principles of Operations should be available at GA.
John Ehrman

Re: Assembly of G-Type constants not working for me

[John Ehrman]

It's probably because the notations .A and .B represent the DBCS 
codings for those double-byte characters, not the EBCDIC characters . 
and A.

If you can enter data in hex, try assembling G'42C142C2' (where I wrote 
the hex representations of each byte) -- this is the DBCS representation 
of AB

Regards... John 

Re: Assembly of G-Type constants not working for me

[John Ehrman]

You must enter those 4 bytes as hex values, not as 8 EBCDIC characters. (I 
assume you're specifying the DBCS option.)

Regards... John 

Re: Replication factor of a group item

[John Ehrman]

From the description of the DS instruction in the HLASM Language 
Reference: 

The maximum length is 65535 for types X and C, 65534 for G.

For DC, the maximum length for type C is (indeed) 256.

Appendix B has a summary of all DC constant types.

Regards... John 

Re: Replication factor of a group item

[John Ehrman]

Micheal, Could you write DS  0CL(11*133) ? 

Regards... John Ehrman

Re: Redesigning the Principles of Operation Manual

[John Ehrman]

As others have noted, the PoP is quite large and dense.  Changing the 
formatting would be a significant effort.

The z Architects are always very busy, and I suspect would have difficulty 
finding resources needed to adopt any of the suggestions on this list.

Regards... John 

Re: Redesigning the Principles of Operation Manual

[John Ehrman]

Robin Vowels noted: 

CVB and CVD have always been part of the fixed-point instruction
set (the basic set), and are not part of the decimal set.

That's what my antique Green Card says!

Re: What does the 'end' address on a USING statement mean?

[John Ehrman]

I believe the USING range limits are currently tested only for unsigned 
12-bit displacements; you happen to have chosen a test case in which the 
LG instructions use signed 20-bit displacements.  To see the effects of 
USING range limits, try dropping a zero from the ends of all the offsets, 
and change the LG instructions to L, which uses the 12-bit displacement.

Regards... John 

Re: Wrapping it up

[John Ehrman]

Wish you well, Steve, and I appreciate your contributions both at SHARE and
to the Assembler List.

Regards... John
-
555 Bailey Ave, San Jose CA 95141 USA
+1-408-463-3543 (fax -3873) TIE 543-
ehr...@us.ibm.com; VMID = EHRMAN at STLVM27

Re: PL/X (Was CamelCase Field Names)

[John Ehrman]

Tony Harminc noted:
 There were a number of efforts to produce compatible PL/S compilers
even in the absense of formal language specs, the most notorious of
which was the Rand Corporation's RL/S.

There was also one at Princeton by ?? Varian (Melinda's husband, I think).
It was also squelched by IBM.

Re: PL/X (Was CamelCase...(Was: Re: HLASM continuation...))

[John Ehrman]

Ed Jaffe commented:
If such rewrite were viable, one could argue that all existing ISV
product code would have already been rewritten in METAL or Dignus C,
which it has not. New modules? Possibly. But, not existing ones.

Confirmed by academic studies. See
(1) P.J.Middleton, The Costs of Changing to a Fourth Generation Compiler
Language, J. Programming Languages 2 (1994), pp.67-76.
His conclusion was that changing programming languages should be avoided.
(2) Andrey A. Terekhov, Chris Verhoef, The Realities of Language
Conversions, IEEE Software Nov.De 2000, pp. 111-124.

I referenced both in my SHARE 103 talk Extending the Life Cycle of Legacy
Applications (With Added Thoughts Specific to Assembler Language), New
York, August 2004, session 8132.  A copy is on the SHARE presentation
archives.

Re: Error with dependant USING beyond 4096 bytes

[John Ehrman]

Gil asked why an algebraically equivalent form won't work:

It's because AREA-8192 (in Jonathan Scott's example) is addressable by an
existing base register; but AREA-10 (in your example) is not.

Addressability of the base location is a requirement for Dependent USINGs.

Re: Error with dependant USING beyond 4096 bytes

[John Ehrman]

Gil noted that I wrote:

 Addressability of the base location is a requirement for Dependent
USINGs.

and replied:
 Who made that rule?  Why?  Can it be appealed?  And why
 addressability with 12-bit displacement (you neglected or
 deliberately omitted to say that), rather than one of the
 longer displacement formats?

Because that's how Dependent USINGs work.  (Now.) The fact that existing
USING ranges were designed around (and limited by) 12-bit displacements is
worth pursuing with HLASM development. Submitting an RFE will get you
started.

Re: Error with dependant USING beyond 4096 bytes

[John Ehrman]

Gil asked:
When is an RFE necessary?  Who submitted the RFE to add long
displacement capability other than in USINGs?  Who submitted
the RFE to add z196 capability to HLASM?  Etc.

Support for z196 and long displacements came from IBM Processor
Architecture, as do requirements for supporting new instructions;
customers submit RFEs.  (It's not all that difficult, I assure you.)

Re: Call For Sample Code RADIX13/RADIX55

[John Ehrman]

Paul, your description is unclear.  Can you provide an example of a couple
of typical sets of 8 (non-hex?) input bytes and what you expect as the
corresponding 4 (non-hex??) output bytes?

Can someone provide me with sample code that uses RADIX13 or Modulo55. My
Modulo55 code is burried in a storage locker which I wont be able to get to
until March.

By RADIX13 or Module 55 I mean the conversion routine that takes for
example 8 Characters (non-hex) as input and converts them to 4 Chracters
(non-hex). The Eight Character input is left justified padded with spaces
on the right. It is typically used by CICS Terminal AutoInstall to develope
CICS TERIDs.

FORMAC (was: Carmine Cannatello's book)

[John Ehrman]

FORMAC was a symbolic computation, algebraic manipulation system writtten
(I believe) in PL/I.  All symbolic algebra systems I know of require
variable-precision arithmetic. (I wrote a couple of System/360 assembler
subroutines for George Collins' SAC-1 system in the early 1970s.)

Re: DC CA'[]'

[John Ehrman]

Some of the uncertainty about how HLASM handles EBCDIC, ASCII, and other
code pages may be due to a lack of detail in the explanations. I'll try:

* The mapping of EBCDIC source characters to other forms is limited in
scope (as many have noted).  This was intended.

* HLASM was not designed to accept ASCII source programs.  (On zLinux,
however, a brief test is done on the first record to determine whether or
not to translate the file to EBCDIC as it's read for processing.)

* A CA-type constant simply translates standard EBCDIC source characters
(code page 037) to generate ASCII object bytes (code page 819, I believe).

* The TRANSLATE option lets you specify a translate table to be used for
mapping EBCDIC source bytes to a different object encoding; the default
table is 037-to-819 (I believe).  Several typical translate tables are
provided for common (extended) EBCDIC code pages, but you can write your
own translate table as described in the Programmer's Guide.

If you would like HLASM to accept and/or generate a wider variety of
character sets, submit a Request For Enhancement through the HLASM web
site, or with the help of your friendly local IBM representatives.

Regards... John Ehrman

Re: DC CA'[]'

[John Ehrman]

Paul Gilmartin noted:
After a lot of experimenting and a little RTFM, I learn that the
TRANSLATE option affects the generation of C'...'-type constants.
The Reference explicitly states that TRANSLATE does not affect
generation of CA'...'-type constants, nor do I see a corresponding
option to control the CA'...' mapping.

You can control the CA'...' mapping by implementing your own set of
translation tables for use with the TRANSLATE option.

When that was implemented, we didn't see a need to enter what others have
called the swamp of multiple source and target code pages.

John Ehrman

Re: FLOWASM (Was: Base-less programming)

[John Ehrman]

Kirk Talman noted:
...My first act after checking a program out of Endevor is to remove all
PRINT NOGEN.

No need to change the source; just assemble the program with the PC(GEN)
option; that overrides all PRINT NOGEN statements, including those embedded
in macros that you might not find in a source scan.

John Ehrman

Re: Base-less programming

[John Ehrman]

The distances from instruction to instruction are unchanged; HLASM will
divide by 2 when calculating the halfword offsets.  So, 4+4 rather than 2
+2, etc.

John Ehrman

Re: Relative Branches / IBM macros

[John Ehrman]

Paul Gilmartin asked:
The assembler ought to be
able to reduce any pair of terms having the same relocatability
attribute and opposite sign to an Absolute value?

Is any of this restriction due to Binder's inability to relocate
bit fields of all lengths and offsets (even discontiguous)
supported nowadays in machine instructions?

HLASM does appear to handle paired relocatable terms as absolute:

000 00010 1 rr csect
 R:F  0   2using *,15
003 a  ds   f
044 b  ds   f
08 A718 00044 5lhi  1,b-a
0C 9504 F000  0   6cli  a,b-a
  7end

Extending similar support to the Binder would require major extensions to
existing object module formats; and to date, there seems to have been no
need for it.

John Ehrman

Re: Relative Branches / IBM macros

[John Ehrman]

The reason is that other z platforms (VM, VSE, zLinux) don't support
relative-immediate external references.

An easy way to suppress the diagnostic is to specify SUPRWARN(215) as an
invocation parameter or on a *PROCESS statement at the head of the source
program.

Steve Smith asked:
External relative addressing does work, yet HLASM still warns about this,
e.g. ASMA215W Relative Immediate external relocation in NOGOFF object text
- ESTAE_RESUME 

Is there any cure for this?  My production build process doesn't tolerate
any return code that isn't a multiple of 0.

Re: mixed case or what

[John Ehrman]

Martin Truebner asked:
 Underlying question - what do I have to specify to make it handle
 label HANS as different from Hans or am I totally off target and
 it will never do that.

There is no mixed-case support for *internal* symbols. You can generate
*external* symbols with mixed case and special characters using the ALIAS
instruction.

The COMPAT(CASE) option was provided with HLASM V1R1 (its initial release)
in case people who had written programs using HLASM had to ship the source
code to sites still using Assembler H, which accepted only upper case
characters.

Regards... John

Re: YREGS MACRO doc?

[John Ehrman]

Paul Gilmartin noted:
 XREF doesn't reliably list register references.

That's why HLASM provides a register cross-reference (use the RXREF
option).  It not only references explicit register use, symbolic or not,
but also implicit uses for instructions like LM, M, D, SRDL, and the like.
For example,

LM  R14,R12,12(R13)

shows only three symbol references, but the RXREF shows all sixteen.

Re: APL or IUP

[John Ehrman]

Dave Gibney guessed:
I will guess IUP to be Independent User Program.

I believe it's Installed User Program.

AUTO: John Ehrman is out of the office (returning 07/29/2013)

[John Ehrman]

I am out of the office until 07/29/2013.




Note: This is an automated response to your message  Question About
storing a Value in a Macro sent on 07/21/2013 14:47:57.

This is the only notification you will receive while this person is away.

AUTO: John Ehrman is out of the office (returning 07/08/2013)

[John Ehrman]

I am out of the office until 07/08/2013.

SVL closed for electrical upgrades.


Note: This is an automated response to your message  short video on
instructions sent on 07/05/2013 6:44:13.

This is the only notification you will receive while this person is away.

Re: Assembler teaching sources

[John Ehrman]

Mike Ward asked:
Hello friends, I was wondering if any of you know of any assembler
teaching tools that might be available for free.

What do you need, and at what level(s)?
John Ehrman

Re: FW: Assembler teaching sources

[John Ehrman]

Steve Hazzard wrote:
... - looks like there's not much interest in Assembler these days.

I would like to code more, however the directive is to plug-in a vendor
product instead of RYO - is this what you are hearing from other Sys Progs?

I you are facing issues of converting from Assembler applications to other
languages or products, you may be interested in my presentation at SHARE103
(in New York City) Session 8132 on the potential -- and often hidden and
unexpectedly large -- costs of changing languages.

Re: Good Performing Code (Was: Millicode Instructions)

[John Ehrman]

Performance concerns about individual instructions aren't worth much
effort. Things like operand alignment, data and instruction cache
retention, locality of reference, branch frequency etc. can have really
significant effects.

Remember that CPU speeds have increased much faster than memory speeds --
getting an operand from cache can take a cycle or two, but from memory can
take hundreds or thousands (try causing a page fault!).

Re: Good Performing Code (Was: Millicode Instructions)

[John Ehrman]

Scott Ford asked:
 what are Assembler no nos in performance ...

Here are some examples (from my session 12522 talk at SHARE in San
Francisco):

1.  Memory speed is very slow compared to CPU speed -- for example, use
immediate operands wherever possible
2.  Operand alignment can be very important (doubleword alignment if
possible!)
3.  Don't mix instructions and data -- keep them far apart
4.  Modifying instructions on the fly is performance poison
5.  Minimize Address Generation Interlock (you can put other unrelated
instructions between these two at little or no cost because the CPU has to
wait until the first Load completes before it can execute the second)
   L1,Pointer
   L2,0(,1)
6.  Arrange branches so the fall through path is most frequent
7.  Keep data references close in memory and time
8.  Keep instruction references close in memory and time

That's a start, anyway.
John Ehrman

TRTE and new instructions

[John Ehrman]

We may have lost the original thread on this topic?

Writing a macro to simulate the actions of a new (but not universally
available) instruction has several merits:

(1) The macro can directly emulate the new instruction, or call an internal
or external subroutine; the macro-generated code can be debugged and tested
on its own without requiring testing the entire application that uses it.

(2) Knowing the properties of the end-user's system means you can ship a
version of the application with a simple reassembly that accounts for the
presence or not of the new instruction.

(3) Fortunately, useful new instructions appear in groups, so a simple
SYSPARM or global variable symbol value can determine which of possibly
many such macros should expand to use emulation or the new instruction.

John  Ehrman

Re: Baseless problem

[John Ehrman]

Ed Jaffe noted...

The oldest assembler I ever used was IFOX00. ISTR, it did not
have support for LOCTR but my memory could be faulty.

I think your memory is correct.

As I remember the IFOX assembler used basically the four-pass structure of
Assembler F.  It was developed and supported by a group in Lidingo Sweden
(a suburb of Stockholm?), and its popular publications were done by Jan
Sandzelius. (The Swedish group attended several SHARE conferences while
they were learning skills transfers from the assembler team in San Jose.)

I believe LOCTR was introduced with Assembler H. Due to its having merged
conditional assembly and ordinary-assembly pass 1, any time a location
counter discontinuity was found it had to establish LOCTR-like temporary
location counter that ASMH then resolved at the end of pass 1 in an
interlude.  The LOCTR instruction was apparently a public exposure of
this internal facility.

More than you wanted to know, maybe...

IFOX00/ASMH (Was: Baseless problem)

[John Ehrman]

Tony Harminc commented:
Tony
It's worth remembering that ASMH predates IFOX00. (Well, as far as
customer availability goes; I have no idea what went on inside IBM.)
I have never understood the point of IFOX00; it appears to be a
reimplemention from scratch to the IEUASM specs, with a couple of
trivial functional enhancements, and using reentrant code. Compared to
IEUASM it has no significant performance advantage, appears not to
exploit any particular aspects of virtual storage, the supported macro
and assembler language is essentially identical, diagnostics are no
better, and so on.

I can only guess at the internal politics in play at the time that
must have led to this project, when ASMH already existed and offered
so much more. IBM's usual internal competition, I suppose, but in such
a small subject area...
/Tony

As I remember, ASMH came out in 1971, IFOX in 1972. IFOX was the official
assembler, while ASMH was an internal tool that was almost not announced
(it took a lot of  pressure from field SE's who insisted it made SYSGENs
possible in an afternoon rather than a weekend with ASMF/IEUASM). So
internal politics is correct -- some IBM execs apparently believed that
PL/I would satisfy all future programming needs, and that Assembler
applications would disappear shortly.

IFOX actually had some internal improvements that helped performance: the
second conditional-assembly and first final-assembly passes were merged, as
had also been done in the Waterloo G assembler; both were based on ASMF. I
doubt IFOX was a from scratch implementation.

I gave a short talk on Assembler History at the San Francisco SHARE
conference; look for the proceedings of session 12235.

John Ehrman

Re: Subject: New BAL

[John Ehrman]

John McKown noted...
IIRC, some models of the S/360 had a BAS instruction. But I don't have
an old S/360 POPS to make sure exactly what it did.

My old System/360 Green Card has no BAS, but I believe it was available on
Models 20 and 67.  I don't think it would have been in the 360 PoP.
John Ehrman

Re: Subject: New BAL

[John Ehrman]

This green card documents BAS as Branch and Store with footnote (e)
Model 67.


http://archive.computerhistory.org/resources/access/text/2010/05/102678081-05-01-acc.pdf

Must be newer (and therefore less green) than mine (X20-1703-3).

Re: Relative Branches / IBM macros

[John Ehrman]

And only if the target is relatively addressable. I.e. In the same section
or object.

sas (phone)
On Apr 5, 2013 7:21 PM, John Ehrman ehr...@us.ibm.com wrote:
 You can use LARL to replace LA only if the target is at an even address.
 John Ehrman

This may not be relevant to the original question, but you CAN declare an
external symbol in the operand field of a relative-immediate instruction.

The object module encodes the relative-adcon type and the binder resolves
the external reference (again assuming the target is at an even address).

John Ehrman

Re: Relative Branches / IBM macros

[John Ehrman]

You can use LARL to replace LA only if the target is at an even address.

John Ehrman

Re: ASMPUT

[John Ehrman]

I am trying to use ASMPUT and need help with creating ADATA file.  Can
anyone point me to a user manual on ASMPUT, thanks.

The Toolkit User Guide is GC26-8710.
John Ehrman

Re: How to print a floating point number

[John Ehrman]

z machines support three different and quite distinct floating-point
representations; printing their values correctly is quite difficult, even
though it's easier for decimal floating-point than for hexadecimal or
binary.

Displaying approximate values is much simpler, but still requires
familiarity with the representation you're working with.

John Ehrman

Re: Extended Mnemonics After Unsigned Arithmetic

[John Ehrman]

Alex Kodat noted:

 ... depends on one's view of the assembler. If the view is that it's gone
about as fer as it can go ...

Oh, there's lots more we'd love to do, had we but world enough, and time.
8-)

John Ehrman

Re: Extended Mnemonics After Unsigned Arithmetic

[John Ehrman]

Paul Gilmartin noted:

Isn't there lately a construct that explicitly invokes a macro rather than
an opcode?  There should be.

There is indeed!  Suffix ':MAC' or ':ASM' as appropriate, as in 'MSG:MAC'
and 'MSG:ASM'.

John Ehrman

Re: Load and Add

[John Ehrman]

 People are prepared to argue PoPs interpretation with John Ehrman ???.

I appreciate the laudatory comment, but I'm as blunder-prone as anyone
else.  (And a very poor chess player.)

To me, the topic we're discussing is with the word operand.

(1) In the PoP, an operand is an object being operated on by, or involved
in, an instruction.

(2) In an Assembler Language statement, an operand is determined by its
sequential position in the operand field of the instruction.

(3) You can also make a case for an operand being an object to which
something happens at execution time.

Assembler Language can be even more difficult if the intended sense isn't
clear from context.

Re: Load and Add

[John Ehrman]

Martin Truebner asked:

wouldn't that be ALSI and ALGSI? With LAA/LAAG/LAAL/LAALG the load
from memory-part is missing.

As I understand the PoP, it says:

The second operand is added to the third operand,
and the sum is placed at the second-operand location.
Subsequently, the original contents of the second
operand (prior to the addition) are placed
unchanged at the first-operand location.

Because the second operand is addressed by a 20-bit displacement, and the
first and third operands are in registers, it appears that the 2nd operand
is brought from memory, added, and the sum put back.

I hope that helps!

Re: Load and Add

[John Ehrman]

I'm looking at LAA on page 7-222 of SA22-7832-09, where the 2nd operand has
B2 | DL2 | DH2.

John Ehrman

AUTO: John Ehrman/Santa Teresa/IBM is out of the office.

[John Ehrman]

I am out of the office until 02/11/2013.




Note: This is an automated response to your message  Re: SVC 34 sent on
02/06/2013 14:26:23.

This is the only notification you will receive while this person is away.

Re: OPSYN Self Execution

[John Ehrman]

Try a technique like that illustrated in this example:

Macro ,  Defined in the source program
L  READ   A,B,C
READ_XX OpSyn  READ  Save Wrapper's definition as READ_XX
READOpSyn  , Nullify this macro's definition
- - -...perform 'front-end' processing
L  READ   A1,B1,C1   Call system version of READ
- - -...perform 'back-end' processing
READOpSyn  READ_XX   Re-establish Wrapper's definition
MEnd

Re: Dependant Using Problem

[John Ehrman]

The problem is with the original USING range: the HLASM Language Reference
says that if the upper limit of the USING range exceeds the lower limit
+4095, it's reduced to that value.  That's why the labeled dependent USING
for EXT2 is flagged.

Apologies for the tardy response.

Dave Kreiss wrote (on Sept 26 2012):

I have this structure that occurs beyond 4096 bytes in another structure
which is addressable.  I am trying to map that structure but the assembler
flags that USING.  The stripped down version of the code follows.

The OK3 STY instruction should be equivalent to the FAILS4 STY instruction
but because the EXT2 USING is flagged the FAILS4 STY is also flagged.

I'm thinking the flagging of the EXT2 USING is an assembler bug.  HLASM is
R6.0 at UK73634 on z/OS 1.13.

ROUTINE  CSECT
 USING (WRK,WRK+L'WRK),15
EXT1 USING BLK,BLOCK1
EXT2 USING BLK,BLOCK2
** ASMA307E No active USING for operand BLOCK2
OK1  STY   1,BLOCK1+BLKWD1-BLK
OK2  STY   1,BLOCK2+BLKWD1-BLK
OK3  STY   1,EXT1.BLKWD1
FAILS4   STY   1,EXT2.BLKWD1
** ASMA010E Invalid use of symbol qualifier - EXT2.BLKWD1
*
BLKDSECT DSECT
BLKWD1   DSA
BLKWD2   DSA
BLK  EQU   BLKDSECT,*-BLKDSECT
*
WRKDSECT DSECT
BLOCK1   DSXL(L'BLK)
 DS2048X
 DS2048X
BLOCK2   DSXL(L'BLK)
WRK  EQU   WRKDSECT,*-WRKDSECT
*
 END

Re: Impossible - generic macro prototype

[John Ehrman]

This reply has been edited to save space --

The types are fixed by the verb: SETAF, SETBF, or SETCF.

As noted in an earlier post, there's no SETBF statement.

 What happens if an external function called with a SETB-type
 argument attempts to return, for example a SETC-type result?

You can do this by substituting your boolean variable into a character
argument, as in
Cval   SETC   'MyCFunction','Boolval'

 Must the arguments and results of external functions be self-
 defining terms, or may the be, for example, relocatable address
 values?

You can pass any character string to a SETCF function, and any arithmetic
value to a SETAF function.  However, because conditional assembly is done
during the first assembly pass and relocatable address values aren't
determined untili the very end of that pass, it's unlikely that you'd be
able to pass relocatable values successfully in most cases.

 What are the first-class objects of HLASM (at assembly time, not at
execution)?

I'm not sure what first-class implies -- could you elaborate?

As a tentative guess, I'd list (1) symbols, (2) control sections, (3)
location counters. Perhaps anything that appears in the object module?

Re: Impossible - generic macro prototype

[John Ehrman]

John McKown asked:
I likely want something that is really impossible. I would like to write a
macro which does not specify any parameters, but can dynamically detect
them in the macro itself. For positional parameters, this could likely be
easy via SYSLIST.

Not at all impossible!  Try something like this, where you can pre-process
and post-process a library macro.  You must define your macro inline, not
in the same SYSLIB sequence as the macro you want to front-end.

Macro ,  Defined in the source program
L  READ   A,B,C
READ_XX OpSyn  READ  Save Wrapper's definition as READ_XX
READOpSyn  , Nullify this macro's definition
- - -...perform 'front-end' processing
L  READ   A1,B1,C1   Call system version of READ
- - -...perform 'back-end' processing
READOpSyn  READ_XX   Re-establish Wrapper's definition
MEnd

This is one of several unusual macro techinques described in my SHARE
presentation; see the proceedings of the Anaheim SHARE conference in August
2012, Sessions 11194-5.  (The title of the session calls the HLASM macro
language A++ because it's the most advanced macro facility in any
programming language I know of.)

John Ehrman.

Re: Impossible - generic macro prototype

[John Ehrman]

John Gilmore asked:
 ... Why can I not write my own
functions?  I understand---perhaps incorrectly---that a
control-block-overflow problem currently precludes implementing more
BIFs; but making it possible for me to write my own, locally defined
functions should be a much easier thing to do.

You can write your own external functions that can be called from the
conditional assembly statements SETAF and SETCF. They are loaded
dynamically when first invoked, and can not only perform operations not
currently supported by HLASM's internal functions, but can also access the
assembly environment to (for example) capture information about the CPU on
which the assembler is executing.

Will that help, or do you have something else in mind?
John Ehrman

Re: ASMLANGX files

[John Ehrman]

Dave Cole asked:
Does anyone know if the internal format of ASMLANGX files has been
published?

Why do you want to know?

Re: flowcharting

[John Ehrman]

Kirk Talman commented:
A business person at our company asked me if it was possible to flowchart
HLASM programs.

The ASMPUT (Program Understanding Tool) component of the HLASM Toolkit
Feature creates flowcharts of one or more assembler programs, with links
between nodes on the graph and the source lines associated with that node.
It uses the ADATA file, and does not rely on the listing.

It's documented in Chapter 4 of the Toolkit Feature User's Guide,
GC26-8710.

Re: Model 2827 New Instructions

[John Ehrman]

Tony Harminc commented:

I see that SA22-7832-09 is now available on ResourceLink. That
Transactional Execution is cool stuff, or would be if I could find a
use for it. Like most things these days, it seems that Java is the
likely exploiter.

We hope to give a presentation on TE at the next SHARE conference in San
Francisco, Feb. 3-8 3012.

Re: Model 2827 New Instructions

[John Ehrman]

On Tue, Sep 18, 2012 at 1:23 PM, McKown, John
john.mck...@healthmarkets.com
 wrote:

 Damn, it's 100 years until that Share presentation? Or, by chance, did
you
 mean 2013? GRIN--


1000 years John... ;-)

I meant 2013 (next year). Even if I'm not around in 1000 years, IBM
mainframes will be...   8-)

Re: which instructions should I use?

[John Ehrman]

Binyamin Dissen commented:
Yes, the difference between real world programming and ivory tower
programming. In real world programming you want the sequences to be
familiar so that others can more easily maintain the programs. Those
with a view from the top of Mt. Olympus may think otherwise, but their
views are not practical for real life.

But be careful: I've seen many examples of poor coding practices that --
simply because they were familar -- were propagated from one program to
another, to the detriment of all.

Re: which instructions should I use?

[John Ehrman]

John McKown wrote:

As an example of (1), I quite often do:

CALL PROGRAM,(PARM1,PARM2),VL
CHI  R15,=Y(MAXENTRIES)
JH   INVALID_RC
B*+4(R15)
START   JRC0
JRC4
JRC8
MAXENTRIES EQU *-START/4

There's no need for a based branch: just write

JH   INVALID_RC  (as before)
LARL  0,START
AR   15,0
BR   15
START   JRC0
JRC4
JRC8

You can check that the return code is a multiple of 4 with a TMLL
instruction:

TMLL  15,B'0011'
JNZ BadRetCode

Re: Strange PC entry

[John Ehrman]

Binyamin Dissen noted:
For some unknown reason, the assembler requires EQU to be in a section,
be it  CSECT or DSECT. Move the REGS macro after the CSECT.


The assember must assume that an EQU statement might depend on a location
counter value, so it must establish a control section if none already
exists.

Re: length of DSECT

[John Ehrman]

Paul Gilmartin noted:

 And I have an example where base and displacement are
 successfully evaluated in an R[SX] instruction where an
 S-constant with the same argument in apparently the same
 context causes an error.

and later posted this example:

 R:2  0   2  USING *,R2
00 4140 204800048 3  LAR4,=F'42'
044  DCS(=F'42')
** ASMA030E Invalid literal usage - =F'42')
** ASMA435I Record 4 in user.NEGD64.JOB07226.D101.? on volume:

The reason the literal is invalid in the S-type (or similar) constant is
that parsing it would require recursive entry into the DC operand
processor.

Two observations: (
(1) Given the extreme constraints on early assemblers (e.g. handle the full
language in 18K memory), it was quite reasonable to limit such syntax.
(2) Since a literal is just a convenient name for a constant, the same
function as in statement 4 above could be achieved by writing
DC  S(F42)  followed by
F42 DC  F'42'

John Ehrman

Re: Difference between ASMA90 and IEV90

[John Ehrman]

Jake Anderson asked
 is IEV90 supported ?

IEV90 (Assembler H V2) was withdrawn from service on October 31, 1995.
Its replacement is the IBM High Level Assembler V1.6 (ASMA90).
All previous releases of ASMA90 have been withdrawn from service.

Re: length of DSECT

[John Ehrman]

Paul Gilmartin noted:

And I have an example where base and displacement are
successfully evaluated in an R[SX] instruction where an
S-constant with the same argument in apparently the same
context causes an error.

Can you post an example?

AUTO: John Ehrman/Santa Teresa/IBM is out of the office.

[John Ehrman]

I am out of the office until 07/30/2012.




Note: This is an automated response to your message  Re: Subject: AW: **
ASMA030E Invalid literal usage -  =CL8'MARTINWH' sent on
7/23/12 9:05:14.

This is the only notification you will receive while this person is away.

Re: HLASM - 20 years old

[John Ehrman]

Happy Birthday!   Do we assemble at SHARE for a party? ;-)

I'd love to, but I can't be at the next SHARE in Anaheim. ;-(

John Ehrman

Re: Base registers

[John Ehrman]

 ... I prefer using Branch Relative, Relative (such as LARL vice LAY),
and Immediate (such as LHI vice LH) instructions. And I do recognize that
it is not always possible, such as accessing locations outside of the
enclosing CSECT.

That would require an enhancement to Binder.  But that's not
unthinkable.  But it would introduce a class of addressability
errors that could be detected only at link time, not at assembly.
Probably not justified by ROI.

Relative-immediate references to external symbols has been available for
both old OBJ and new GOFF object formats since 2004.

John Ehrman