length of DSECT

[Frank Swarbrick]

I always want things I can't have...

Given the following:

ABC      DSECT ,         
HALFWORD DS    H         
FULLWORD DS    F         
DBLWORD  DS    D         
ABC_LEN  EQU   *-ABC     
BASIC    CSECT ,         
T1       DS    CL(L'ABC)  
T2       DS    CL(ABC_LEN)
                               Ordinary Symbol and Literal Cross Reference   
Symbol   Length   Value     Id    R Type Asm  Program   Defn References      
ABC           1 00000000 FFFFFFFF     J                    1    5    10      
ABC_LEN       1 00000010 FFFFFFFF A   U                    5    9            
BASIC         1 00000000 00000001     J                    6   17    69    70
T1            1 00000000 00000001     C  C                 9
T2           16 00000001 00000001     C  C                10

                                                Dsect Cross Reference
Dsect     Length      Id       Defn                                  
ABC      00000010  FFFFFFFF       1                                 

L'ABC gives me 1 (one) rather than what I want, 16 (10h).  Is there any symbol or whatever I can use that returns me the same length value of a Dsect that is listed in the Dsect Cross Reference report?

Thanks,
Frank

[Litwinowich, David]

I am currently out of the office, returning Monday, August 20.

[McKown, John]

If you want L'ABC to be anything other than 1, you can't:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ASMR1020/5.20
<quote>
If symbol denotes an ordinary symbol, the ordinary symbol identifies the dummy section. If several DSECT instructions within a source module have the same symbol in the name field, the first occurrence initiates the dummy section and the rest indicate the continuation of the dummy section. The ordinary symbol denoted by symbol represents the address of the first byte in the dummy section, and has a length attribute value of 1.
</quote>

In the above, you'd use ABC_LEN as a self-defining term.

MVC ABC(ABC_LEN,base-reg),ACB_INIT


On thing that I do to guarantee that the length of ABC and ABC_INIT are exactly the same length is like:

ABC DSECT
...
ABC_LEN EQU *-ABC
...
csect CSECT
ABC_INIT DS 0D
...
ABC_INIT_LEN EQU *-ABC_INIT
VAL_ABC_INIT DS (ABC_INIT_LEN-ABC_LEN)C #Should be 0
VAL_ABC DS (ABC_LEN-ABC_INIT_LEN)C #Should be 0

If ABC_LEN is not equal to ABC_INIT_LEN, then one of the two above will have a negative repetation count and will cause a assembler error.





--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets�

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� is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company�, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

[Martin Truebner]

Frank,

>> Dsect Length Id Defn
ABC 00000010 FFFFFFFF 1

and

>> L'ABC gives me 1 (one) rather than what I want, 16 (10h).

I was as surprised as you were- only the moment was different - I
looked at length of DSECT in an ADATA-exit and found that HLASM does
know the length of a DSECT (and so shows the listing in the DSECT
XREF).

Question- would it really change anything (to unusability), if HLASM
would return the proper length and not 1?

--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de

[John Ehrman]

Worth considering; added to the HLASM "Wish List".

[Paul Gilmartin]

On Aug 6, 2012, at 12:03, Martin Truebner wrote:
>
>>> Dsect Length Id Defn
> ABC 00000010 FFFFFFFF 1
>
> and
>
>>> L'ABC gives me 1 (one) rather than what I want, 16 (10h).
>
> I was as surprised as you were- only the moment was different - I
> looked at length of DSECT in an ADATA-exit and found that HLASM does
> know the length of a DSECT (and so shows the listing in the DSECT
> XREF).
>
> Question- would it really change anything (to unusability), if HLASM
> would return the proper length and not 1?
>

o It would be more useful, but it would surely break some
existing code.

o Some programmers resort to:

DUMMY DSECT
... , stuff
NAME EQU DUMMY,*-DUMMY

o But are length attributes even today allowed to be >256?
(See first bullet.)

o Remember, all this art originated in assemblers that didn't
do any lookahead. Even today, will HLASM do any lookahead to
define a length attribute? Much could be solved by defining
data areas before executable code, but many programmers don't
like that.

On Aug 6, 2012, at 12:48, John Ehrman wrote:

> Worth considering; added to the HLASM "Wish List".

o It would need to be controlled by an option, either global
or on the DSECT statement in order not to break existing
code.

-- gil

[Gainsford, Allen]

On 7/08/12 7:03 AM, "Paul Gilmartin" <PaulGB...@aim.com> wrote:

>>Question- would it really change anything (to unusability), if HLASM
>> would return the proper length and not 1?
>>
>o It would be more useful, but it would surely break some
> existing code.

Really? If the length is currently defined to be 1, then it seems to me
that any code currently using it would be either (a) broken, or (b)
deliberately expecting a value of 1, and therefore unnecessarily obscure.
Of these, (a) seems much more likely, and thus the proposed change to
HLASM might actually help. I don't discount the possibility of (b), mind
you...

Regards,
Allen

[John Gilmore]

Implicit dependencies are much more important than explicit ones.
Changes in the long-established behavior of a translator, even when
they correct a notional error, inevitably break much old code; and
they do so in ways that are difficult to anticipate.

If different behavior is required, the better thing to do is to
introduce a new, and newly named, facility that provides it.

John Gilmore, Ashland, MA 01721 - USA

[Gainsford, Allen]

On 7/08/12 1:41 PM, "John Gilmore" <jwgl...@gmail.com> wrote:

>Implicit dependencies are much more important than explicit ones.
>Changes in the long-established behavior of a translator, even when
>they correct a notional error, inevitably break much old code; and
>they do so in ways that are difficult to anticipate.
>
>If different behavior is required, the better thing to do is to
>introduce a new, and newly named, facility that provides it.
>
>John Gilmore, Ashland, MA 01721 - USA

True enough. The sad thing is that this approach, while far more
backwardly compatible, can leave a translator (or any other tool or
facility, for that matter) supporting a lot of "broken" behaviours
indefinitely. The translator, or facility, or whatever, can become a
nightmare to maintain because it's so weighed down with the past. It also
becomes harder to use because the documentation becomes similarly weighed
down.

Not, I suppose, that this is news to anyone reading this list. :)

Allen Gainsford

[Paul Gilmartin]

On Aug 6, 2012, at 20:38, Gainsford, Allen wrote:

> On 7/08/12 1:41 PM, "John Gilmore" wrote:
>
>> If different behavior is required, the better thing to do is to
>> introduce a new, and newly named, facility that provides it.
>

Or, I would say, a new option for an existing facility.

> True enough. The sad thing is that this approach, while far more
> backwardly compatible, can leave a translator (or any other tool or
> facility, for that matter) supporting a lot of "broken" behaviours
> indefinitely. The translator, or facility, or whatever, can become a
> nightmare to maintain because it's so weighed down with the past. It also
> becomes harder to use because the documentation becomes similarly weighed
> down.
>

The pity is there's so little evidence of specification or
design of HLASM. It jes' growed. A dreadful example is that
divide checks evaluating arithmetic expressions are not reported
as errors. 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.

-- gil

[Steve Hobson]

Why not change the Assembler to generate an error message when code uses
the implied length of a DSECT name? I see no reason for writing such code
other than to confuse the reader. And we should discourage that. The
change could not cause hard to debug behaviour changes. It could, though,
identify long-standing errors that no-one noticed yet.

Steve Hobson

Je me presse de rire de tout, de peur d'être obligé d'en pleurer

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[John Gilmore]

Paul Gilmartin's view of the HLASM (and much else) is negative. His
focus is on things to deplore.

I in turn deplore his focus. The HLASM has a long history and is
still evolving. I find that I can use it to get my work done. I must
sometime write a macro, resort to SETAF, or do some other uncongenial
thing in order to do so, but I can get my work done.

I do not, that is, expect the HLASM to reflect my world view exactly,
not least because my world view is radically different from, say, Mr.
Gilmartin's.

Why these musings? There is a sense in which this thread is otiose.
All of us presumably know how to determine the length of a DSECT, and
the fact the L'<DSECT name> returns 1 as its value is not really very
important.

There is some language in Through the looking glass that is apposite
here: "When I use a word," Humpty Dumpty said, in a rather scornful
tone, "it means just what I choose it to mean�neither more nor less."

This is a strategy open to all of us in our own speech and writing.
We cannot, however, expect to be able to impose our own eccentric
choices upon translators written by others.

[Kirk Talman]

Over the decades, I too have complained of the triumph of development over
design in various human creations. I have come to understand that even
the best designs grow old and cannot be adapted to new challenges, much as
is true of myself.

I taught myself assembler about 4.5 decades ago and have used it on three
different architectures. Hlasm and its predecessors have served me well
in the interim. I am thankful for those who created it and for those who
keep it in existence. While there are preprocessors and program
generators lurking in many corners, I know of no other language that has a
powerful, built-in tool as the HLASM macro language. I have enjoyed using
it to enhance my own and others productivity, and to build, grow and
repair software solutions in a number of industries.

Ad multos annos!

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
08/07/2012 03:13:25 AM:

> The pity is there's so little evidence of specification or
> design of HLASM. It jes' growed. A dreadful example is that
> divide checks evaluating arithmetic expressions are not reported
> as errors. 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.

-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you

[Ray Mullins]

On 2012-08-06 11:48, John Ehrman wrote:
> Worth considering; added to the HLASM "Wish List".
>

While we're at it, if it's not too much trouble (there's the escape clause),
the length attribute for any xSECT would be a nice touch.

--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/

German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi
French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson
English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBont�]

[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?

[Paul Gilmartin]

Sure. Much excerpted, but it shows the idea:

� R:2 00000 2 USING *,R2
�000000 4140 2048 00048 3 LA R4,=F'42'
�000004 4 DC S(=F'42')
�** ASMA030E Invalid literal usage - =F'42')
�** ASMA435I Record 4 in user.NEGD64.JOB07226.D0000101.? on volume:
� 5 *

Thanks,
gil

[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 00000 2 USING *,R2
000000 4140 2048 00048 3 LA R4,=F'42'
000004 4 DC S(=F'42')
** ASMA030E Invalid literal usage - =F'42')
** ASMA435I Record 4 in user.NEGD64.JOB07226.D0000101.? 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

[Bhuvanakumar Shanmugam]

In Tranining between 9:00 AM IST to 1:00 PM IST

Please do not print this email unless it is absolutely necessary.

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. 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.

www.wipro.com

[Bill Fairchild]

Okay. I promise I won't print it if you promise you won't send me any more emails unless they are absolutely necessary.

And I am the sole determiner of what is necessary, not you.

Please find a way not to send an automated reply to any server list such as the ASSEMBLER-LIST, because your automated reply to the one sender (ASSEMBLER-LIST) causes the Assembler List to send automatically a copy of your automated reply to hundreds of recipients like myself, most of whom probably judge your reply as not absolutely necessary. Perhaps you could try to add ASSEMBLER-LIST to an exclude list?

Bill Fairchild