Look-ahead question
Abe Kornelis
Does anybody know of a way to tell in advance
whether or not a specific field will be defined
before its mapping macro is invoked?
I have not been able to find a solution.
After a field has been defined (DS or DC) I can
of course use the D' attribute. But to my
knowledge, this will not work *before* the
field in question has been defined.
I need to take action before the field is
actually defined...
Thanks in advance for any suggestions.
Cheers,
Abe Kornelis.
============
John R. Ehrman (408-463-3543 T/543-)
defined, or 1 if it is; both tests are made at the position in
the program where the attribute reference occurs. D' is meant
to do just what you need (and was invented for that purpose).
John Ehrman
(------------------ Referenced Note Follows --------------------)
Date: Tue, 3 Oct 2006 20:37:53 +0200
From: Abe Kornelis <a...@bixoft.nl>
John R. Ehrman (408-463-3543 T/543-)
Perhaps readers of this list can offer suggestions?
John Ehrman
(------------------ Referenced Note Follows --------------------)
From: Abe Kornelis <a...@bixoft.nl>
<...>
Unfortunately, I still need to know some details *before* the
mapping macro is invoked. I think I can build my own solution
to circumvent this problem.
Abe Kornelis
thanks for your quick answer. I've taken today's luch break
to test your remarks. I think there's been a misunderstanding.
You state the D' attribute was designed especially for the
purpose I had in mind. Well - it does not test whether a field
will be defined - it only tests whether or not a field has been
defined prior to the D' attribute reference.
This is a very useful feature, but in this case, I need to know
in advance whether or not invocation of the mapping macro
will or will not generate a given field. D' does not tell in advance,
not even in open code....
I think Roland Schiradin was closer by stating that it is impossible
to check in advance. I'll have to create my own solution.
Thanks,
Abe.
===
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.407 / Virus Database: 268.12.12/462 - Release Date: 3-10-2006
>
>
Abe Kornelis
Thanks for your reply. You are right - there is no standard way
of knowing in advance. And I agree entirely with your suggestion.
I already define all DSECTs before the executable code.
Unfortunately, I still need to know some details *before* the
mapping macro is invoked. I think I can build my own solution
to circumvent this problem.
Cheers,
Abe.
===
> AFAIK No you may need to change the location of all definition or macros
> to the beginning of your code.
>
> Roland
>
>
> -----Original Message-----
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Abe Kornelis
> Sent: Tuesday, October 03, 2006 8:38 PM
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Look-ahead question
>
>
> Hello all,
>
> Does anybody know of a way to tell in advance
> whether or not a specific field will be defined
> before its mapping macro is invoked?
>
> I have not been able to find a solution.
>
> After a field has been defined (DS or DC) I can
> of course use the D' attribute. But to my
> knowledge, this will not work *before* the
> field in question has been defined.
>
> I need to take action before the field is
> actually defined...
>
> Thanks in advance for any suggestions.
>
> Cheers,
> Abe Kornelis.
> ============
>
>
Edward Jaffe
> You state the D' attribute was designed especially for the
> purpose I had in mind. Well - it does not test whether a field
> will be defined - it only tests whether or not a field has been
> defined prior to the D' attribute reference.
>
> This is a very useful feature, but in this case, I need to know
> in advance whether or not invocation of the mapping macro
> will or will not generate a given field. D' does not tell in advance,
> not even in open code....
If you can foretell the future, can you then take steps to alter it?
Such a conundrum/paradox might be fun to ponder while under the
influence of mind-altering chemicals. But, in the real world of
assembler language programming, a "crystal ball" seems like an
unreasonable request to me.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Michael Stack
Mike
Michael Stack e-mail: mst...@niu.edu
ear-mail: 1.815.753.9447
Computer Science Department fax: 1.815.753.0342
Northern Illinois University www: http://mstack.cs.niu.edu
DeKalb, IL 60115 skype: callto://mstack
Baron Carter
The Cat: That depends a good deal on where you want to get to
Alice: I don't much care where.
The Cat: Then it doesn't much matter which way you go.
Alice: …so long as I get somewhere.
The Cat: Oh, you're sure to do that, if only you walk long enough.
Baron Carter
Rocket Software Inc
glen herrmannsfeldt
> If you can foretell the future, can you then take steps to alter it?
> Such a conundrum/paradox might be fun to ponder while under the
> influence of mind-altering chemicals. But, in the real world of
> assembler language programming, a "crystal ball" seems like an
> unreasonable request to me.
It would be possible to do with more than two passes, though
I don't know of any assemblers that do it.
For assemblers, a similar problem comes up when deciding
between short and long branch instructions.
LaTeX has a related problem for doing table of contents and
other page references. The LaTeX solution involves running
LaTeX multiple times, each time it reads in a file that it
previously wrote. Usually this converges to the right solution
fairly fast, though there could be cases that don't converge.
-- glen
Binyamin Dissen
wrote:
:>Abe Kornelis wrote:
:>> You state the D' attribute was designed especially for the
:>> purpose I had in mind. Well - it does not test whether a field
:>> will be defined - it only tests whether or not a field has been
:>> defined prior to the D' attribute reference.
:>> This is a very useful feature, but in this case, I need to know
:>> in advance whether or not invocation of the mapping macro
:>> will or will not generate a given field. D' does not tell in advance,
:>> not even in open code....
:>If you can foretell the future, can you then take steps to alter it?
:>Such a conundrum/paradox might be fun to ponder while under the
:>influence of mind-altering chemicals. But, in the real world of
:>assembler language programming, a "crystal ball" seems like an
:>unreasonable request to me.
Allow a first pass to get as much symbol information as possible, and then
start assembling on the second pass.
I find DSECTs at the beginning of the program to be quite ugly.
--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
glen herrmannsfeldt
> http://www.fortran.com/come_from.html
There is also debug packets and the AT statement
implemented in the Fortran G compiler, somewhat
similar to what one could do with COME FROM statements.
It lets you put debugging code at the end of the
subprogram, and print out or otherwise check values
at the appropriate place in the program.
I never tried it, and don't know how they implemented it.
-- glen