Paul Gilmartin's original post remade a point a,lready made by the
HLASM Language Reference in the words:
The type attribute can change during an assembly. The lookahead
search might assign one value, whereas the symbol table at the end of
the assembly might display another.
I could wish for the
On Nov 7, 2011, at 06:02, Abe Kornelis wrote:
> Replying to an old message by Paul Gilmartin:
>> How many passes does HLASM make over the source?
> Two passes.
>
>>> This could lead to a situation where the displacements oscillate
>>> back and forth for each pass.
>> Similar problems exist with th
Replying to an old message by Paul Gilmartin:
How many passes does HLASM make over the source?
Two passes.
This could lead to a situation where the displacements oscillate
back and forth for each pass.
Similar problems exist with the old-fashioned type attribute.
I can code a test which, depe
I am currently out of the office. For assistance please contact:
Pat Bowman at pat.bow...@opensolutions.com, 713.965.1458
Ray Waters at ray.wat...@opensolutions.com, 713.965.8451.
NOTICE:
This e-mail is intended solely for the use of the individual to whom it
I like the idea and I think it could have value, at least in certain instances.
However, it seems to me that the case for BRASL would likely be more difficult
for the Assembler to characterize. The biggest CSECT that I've ever written
was about 30K of executable code. (I believe that things g
On Oct 14, 2011, at 15:27, John Ehrman wrote:
>
> (1) Addresses and offsets aren't known until the end of the first pass over
> the source, when the values of all symbols are known. This means it's
> difficult to capture the needed information in time for use by conditional
> assembly.
>
How many p
On Oct 14, 2011, at 14:15, McKown, John wrote:
> This is just a thought that I had. I'd appreciate feedback about its utility.
> HLASM currently can do some tests on symbols, such at "type" (T'SYMBOL) or
> "length" (L'SYMBOL) and others. I thought it might be useful to have another
> test to se
An interesting idea, but there are a couple of potential problems:
(1) Addresses and offsets aren't known until the end of the first pass over
the source, when the values of all symbols are known. This means it's
difficult to capture the needed information in time for use by conditional
assembly.
This is just a thought that I had. I'd appreciate feedback about its utility.
HLASM currently can do some tests on symbols, such at "type" (T'SYMBOL) or
"length" (L'SYMBOL) and others. I thought it might be useful to have another
test to see if the symbol can be resolved via as "relative" operan
