Glen,
>> Now that I write that, where is the STM 14,12,12(13)?
Could be a VSE main program.
In VSE you don't have to use std-linkage conventions for batch_mainlines
(but you can since 35 (or so) years). Old method: no linkage and at end
of work an SVC 0E (EOJ SVC).
Source for major headaches f
At 18:44 + on 06/04/2012, Bodoh John Robert wrote about Re: Base registers:
The code we use here at my job usually has very large modules and
used several base registers. I have seen the following technique
used:
MYCSECT CSECT
USING *,R15
B BYID
ID DCC'modu
I have taxed other people with not having mastered details, but I must
admit that I did not know that
| DCF'2 147 483 647'
was licit. In the interests of coherence, it should be possible to write
| DCF'2_147_483_647'
if it is possible to write
|FMAX EQU 2_147_4
All the time
Scott ford
www.identityforge.com
On Jun 4, 2012, at 8:36 PM, robin wrote:
> From: John Gilmore
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Sent: Tuesday, 5 June 2012 7:37 AM
>
>> As an optional usage in coded-arithmetic and hexadecimal constants,
>> where it is unambiguous, this is an
From: John Gilmore
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Tuesday, 5 June 2012 7:37 AM
As an optional usage in coded-arithmetic and hexadecimal constants,
where it is unambiguous, this is an excellent idea.
It has been available in PL/I for a long time, where I may write
Declare Fmax va
Paul Gilmartin noted:
>On Jun 4, 2012, at 15:31, John Ehrman wrote:
>>
>> Blank separators were introduced for quite-delimited numeric constants
in
>> HLASM R3.
>>
>IOW they're permitted in DC, but not in EQU where they're
>not quite delimited.
A necessary restriction, because decimal terms in EQ
On Jun 4, 2012, at 15:31, John Ehrman wrote:
>
> Blank separators were introduced for quite-delimited numeric constants in
> HLASM R3.
>
IOW they're permitted in DC, but not in EQU where they're
not quite delimited.
Sigh.
-- gil
As an optional usage in coded-arithmetic and hexadecimal constants,
where it is unambiguous, this is an excellent idea.
It has been available in PL/I for a long time, where I may write
Declare Fmax value(2_147_483_6747) signed binary fixed(31,0) ;
or
Declare Fmax signed binary fixed(31,0) stati
John McKown suggested:
>It is much easier to recognize 16_777_216 than 16777216.
For constants you can write things like DC F'16 777 216' .
Blank separators were introduced for quite-delimited numeric constants in
HLASM R3.
John Ehrman
(snip, I wrote)
>> But, why the DS 0H instead of putting the label on the LM?
> I do the same thing for "labels" to "code". Why? Hum, I guess
> from reading the HASP code long ago. Also, it makes it
> easier to insert a new instruction at that logical point in
> the program without remembering to
I don't see where this is possible in HLASM. But some languages all a _
character in numeric literals, and simply ignoring it. Often used in decimal
literals to separate thousands, and in binary literals to separate into nybbles
(4 bits). It is much easier to recognize 16_777_216 than 16777216.
Once upon a time, if you wanted to put a label on a separate line you used
DS 0H not EQU * because 1) you got 1/2 wd alignment needed for code and
not possible S0C1s and 2) DS 0H worked with TSO TEST and EQU * did not
> From: glen herrmannsfeldt
> Someone wrote:
> > MYCSECT CSECT
> >
>
> But, why the DS 0H instead of putting the label on the LM?
>
> -- glen
I do the same thing for "labels" to "code". Why? Hum, I guess from reading the
HASP code long ago. Also, it makes it easier to insert a new instruction at
that logical point in the program without remembering to remove t
Someone wrote:
> MYCSECT CSECT
> USING *,R15
> B BYID
> ID DCC'module-name'
> BASESDCA(MYCSECT)
> DCA(MYCSECT+4096)
> DCA(MYCSECT+2*4096)
> DCA(MYCSECT+3*4096)
> BYID DS0H
> LMR9,R12,BASES
>
John McKown writes:
No such thing as a negative displacement. A displacement is more like
an unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12
bit displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long
displacement)
This is is correct only for traditional System/360 i
On Mon, 4 Jun 2012 14:20:09 -0500 "McKown, John"
wrote:
:>No such thing as a negative displacement. A displacement is more like an
unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12 bit
displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long displacement).
You may wish
OOPS. Thanks for the correction! So you could use the 20 bit offset in a
negative direction from the end of the module. Personally, I don't think that
I'll try that! And I generally use "baseless" coding for things in the CSECT,
anyway.
--
John McKown
Systems Engineer IV
IT
Administrative Serv
"The displacement for A is treated as a 12-bit
*unsigned* binary integer. The displacement for AY,
AG, AGF, AGSI and ASI, is treated as a 20-bit *signed*
binary integer."
I contributed the asterisks. The rest is from the POps.
--
Regards, Gord Tomlin
Action Software International
(a division of
No such thing as a negative displacement. A displacement is more like an
unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12 bit
displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long displacement).
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
He
i guess you guys would never set the base to he last byte of the program or
dsect; having all negative displacements.
Can IT be Trusted on Personal Devices (Nos 9,16,41,50).
--Original Message--
From: Scott, Samuel J
Sender: IBM Mainframe Assembler List
To: IBM Mainframe Assembler List
ReplyTo: IBM Mainframe Assembler List
Subject: Automatic reply: Base registers
Sent: Jun 4, 2012 09:05
I will be out of t
The code we use here at my job usually has very large modules and used several
base registers. I have seen the following technique used:
MYCSECT CSECT
USING *,R15
B BYID
ID DCC'module-name'
BASESDCA(MYCSECT)
DCA(MYCSECT+4096)
DCA
Bill,
Amen, I first wrong BAL on a 360/20, didn't have the 1401 exposure ..man half
words were real important
Scott ford
www.identityforge.com
On Jun 4, 2012, at 11:15 AM, Bill Fairchild
wrote:
> I have seen many old IBM modules (in dumps, microfiche, etc.) in which the
> first few instruct
I have seen many old IBM modules (in dumps, microfiche, etc.) in which the
first few instructions are something like this:
MODULE USING *,R15
LRR12,R15
LA R11,4095(,R12)
DROP R15
USING MODULE,R12
USING MODULE+4095,R11
This allows 8,191 bytes of loca
Thanks Gerhard, I feel the same way, especially when you work for a small
company and your the only one writing Assembler, with customers asking for
changes
Scott ford
www.identityforge.com
On Jun 4, 2012, at 2:49 AM, Gerhard Postpischil wrote:
> On 6/3/2012 8:52 AM, John Gilmore wrote:
>> Ge
That was a typo, opinionsour customers usually dictate needs many times
Scott ford
www.identityforge.com
On Jun 4, 2012, at 9:00 AM, Scott Ford wrote:
> Martin,
>
> As the say options are like ...everyone had one...your entitled to yours
>
> Scott ford
> www.identityforge.com
>
> On Jun 4,
I will be out of the office 6/3 thru 6/11. If you need assistance please call
Don Neaves at 817-252-8188 or Darrell Thompson at 817-252-8961. Thanks!
Martin,
As the say options are like ...everyone had one...your entitled to yours
Scott ford
www.identityforge.com
On Jun 4, 2012, at 8:27 AM, Martin Truebner wrote:
> Tony,
>
I have yet to find that VSE-customer that pays for Vendor-software and
>> has no money for hardware or operating-s
Tony,
>> > I have yet to find that VSE-customer that pays for Vendor-software and
> has no money for hardware or operating-system-software AND demands
> new features.
We have several that meet this requirement. Think about the VSE 2.6 on
P390 ESL boxes.
I can imagine customers running that- bu
I think it may have been an parody of a joke:
Question: "How much money is enough?"
Answer: "Just a little bit more."
In assembler, it is "how many bytes do you need to be resolvable to a valid
offset?" "just a few more."
It's why I (as a customer only), love doing "baseless" programming. I sepa
> I have yet to find that VSE-customer that pays for Vendor-software and
> has no money for hardware or operating-system-software AND demands
> new features.
We have several that meet this requirement. Think about the VSE 2.6 on
P390 ESL boxes.
Tony Thigpen
-Original Message -
From: Mar
On Mon, Jun 4, 2012 at 12:20 PM, robin wrote:
> Even with the nonsense word changed a la Martin,
> your response still doesn't make sense.
Sorry, as Martin noticed my head and fingers had disconnected...
Typically I find the module just slightly extend the 4K after a small
change... 4092 or 409
From: Rob van der Heij
Sent: Monday, 4 June 2012 4:41 PM
On Mon, Jun 4, 2012 at 2:45 AM, robin wrote:
There's no need to be scared of an odd value.
It is, after all, the assembler that calculates displacements.
If it bothers you, make it 4092. Still no extra instruction needed.
Since most
>> ?? Doesn't make sense.
Since most of the time you just NEED a few more bytes anyway
Better now?
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
From: Rob van der Heij
Sent: Monday, 4 June 2012 4:41 PM
Since most of the time you just new a few more bytes anyway ;-)
?? Doesn't make sense.
>> ... said enough, maybe too much, about this topic
Since the thread is still not dead- here is my point:
Use of relative & immediate feature is the way to go. The time it takes
to convert a module from Bxx type to Jxxx is neglectable in comparison
to finding an unused register (or restructuring
>> Odd (or nonconsecutive) Base registers
Please-
If there is ever a need to calculate a ZAP to this code with crossing
the boundary between two registers- it will cause major headaches-
The PLS compiler does it- but this is not an argument to do it.
--
Martin
Pi_cap_CPU - all you ever need a
37 matches
Mail list logo
