JG, Thanks for cooperation!
С уважением,
*Валерий Мироненко*
--
Direct: +7 916 688 33 95 | SKYPE: ValMironenko
Email: vmirone...@gmail.com | © 2012 Avronet LLC
--
Это сообщение электронной почты, включая вложения, только для использования
лицом, которому оно было отпр
I do in fact read and, haltingly, speak Russian; and I will be happy
to translate posts to and from Russian in modest volumes, say 8-10 a
day, when I am tuned in.
What I cannot do is provide any guaranty that I will be immediately
available on some particular day to perform this service.
--jg
On
On 2/13/2012 6:59 PM, Steve Smith wrote:
Maybe John Gilmore will provide a witty retort, but you surely must know
that the number of Russian-literate people here is probably pretty low.
Babelfish did nothing but convert this text into HTML entities.
My Russian is rudimentary, so I fell back on
Maybe John Gilmore will provide a witty retort, but you surely must know
that the number of Russian-literate people here is probably pretty low.
Babelfish did nothing but convert this text into HTML entities.
On 2/13/2012 19:24, Valeriy Mironenko wrote:
Bad Idea. Плохая идея-изменение мнемоники
On 14 February 2012 17:41, robin wrote:
> From: Peter Relson
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: Tuesday, 14 February 2012 4:26
>
>
>>Some of this discussion revolves around what the "base knowledge" is that
>>you expect/require that the code's readers have.
>>
>>If "everyone" understa
On 2/13/2012 5:24 PM, Valeriy Mironenko wrote:
Bad Idea. Плохая идея-изменение мнемоники команд. Команды существуют с 1964
года, если что-то не нравится - напиши свои макро и не забудь написать -
PRINT GEN, когда будешь передавать третьим лицам свои исходники.
Я согласен.
--Гиль
Bad Idea. Плохая идея-изменение мнемоники команд. Команды существуют с 1964
года, если что-то не нравится - напиши свои макро и не забудь написать -
PRINT GEN, когда будешь передавать третьим лицам свои исходники.
С уважением,
*Валерий Мироненко*
--
Direct: +7 916 688 33 95 | SKYPE: ValMironenko
E
On 2/14/2012 3:41 PM, robin wrote:
If "everyone" understands that "SR regx,regx" and "XR regx,regx" zero
regx then there is little to no benefit to having a macro that is "ZERO
regx".
If so, there's be little need for comments such as the example
XR R5,R5zeroise R5
Something sensible
(someone wrote)
> IHMO, the mnemonic for BCT was not well-chosen.
> Better might have been DBZ
> for Decrement and Branch on Zero.
That would be Decrement and Branch on Not Zero, DBNZ,
and also DBNZR. Sounds too much like DEC to me.(*)
I believe none of the S/360 instructions are more than f
Ha! I have frequently asked customers to send me a dump, so that I could examine the entrails of the beast (and hopefully track its spoor).David de Jongh On 02/13/12, John Gilmore wrote: After describing his own debugging practices, Gerhard Postpischil writes:For production programs, I prefer to s
IHMO, the mnemonic for BCT was not well-chosen.
Better might have been DBZ
for Decrement and Branch on Zero.
As for the below case of BALR, clearly, there needed to be yet another
instruction :-
DWIM
(Do What I Mean)
-Original Message-
From: Bernd Oppolzer
Date: Saturday, 11 Feb
From: Peter Relson
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Date: Tuesday, 14 February 2012 4:26
>Some of this discussion revolves around what the "base knowledge" is that
>you expect/require that the code's readers have.
>
>If "everyone" understands that "SR regx,regx" and "XR regx,regx" zero
>reg
From: Steve Smith
Date: Monday, 13 February 2012 10:13
>There seems to be a common misconception that MVC can't move 256 bytes.
>It certainly can. It cannot move zero bytes, but that's not much of a
>limitation.
Not from me. I explicitly mentioned 256.
Length field 0 corresponds to a move of
After describing his own debugging practices, Gerhard Postpischil writes:
For production programs, I prefer to save the registers, if useful,
issue one or more explanatory messages, and then issue a user abend.
and this is enough.
Debugging--as opposed to prior and subsequent systematic testin
On 2/13/2012 10:53 AM, McKown, John wrote:
Personally, I do the S0C1 for one reason alone: for
"debugging" purposes. It is just simpler to do than coding up
a good ABEND macro instruction. I'm not say this is for
production use of reporting an error to an end user. I do use
the ABEND and/or DUMP
More real world vs. Ivory Tower, but whatever.
On Mon, 13 Feb 2012 11:11:04 -0500 John Gilmore
wrote:
:>Binyamin and I see the world differently. I judge that he is talking
:>nonsense, and he judges that my arguments are irelevant. So be it.
:>
:>On 2/13/12, McKown, John wrote:
:>> Personally
Some of this discussion revolves around what the "base knowledge" is that
you expect/require that the code's readers have.
If "everyone" understands that "SR regx,regx" and "XR regx,regx" zero
regx then there is little to no benefit to having a macro that is "ZERO
regx".
Drawing the line in the r
Binyamin and I see the world differently. I judge that he is talking
nonsense, and he judges that my arguments are irelevant. So be it.
On 2/13/12, McKown, John wrote:
> Personally, I do the S0C1 for one reason alone: for "debugging" purposes. It
> is just simpler to do than coding up a good AB
Personally, I do the S0C1 for one reason alone: for "debugging" purposes. It is
just simpler to do than coding up a good ABEND macro instruction. I'm not say
this is for production use of reporting an error to an end user. I do use the
ABEND and/or DUMP macros for that. But for a "what the bleep
On Mon, 13 Feb 2012 10:00:42 -0500 John Gilmore
wrote:
:>Binyamin is talking nonsense.
A good way to start a discussion.
:>A USER ABEND has the same DUMP options available to it that are
:>available to any other ABEND.
True, and irrelevant.
:>The notion that the default options supplied for,
Binyamin is talking nonsense.
A USER ABEND has the same DUMP options available to it that are
available to any other ABEND.
The notion that the default options supplied for, say, a judiciously
chosen SYSTEM OCx ABEND can somehow be better than those chosen in a
considered way for a USER ABEND is
On Mon, 13 Feb 2012 09:05:03 -0500 John Gilmore
wrote:
:>We have of course been here before.
:>The idea that a desired USER ABEND is best achieved by triggering a
:>SYSTEM ABEND that will be minimally confusing, highly unlikely to be
:>confused with the corresponding real SYSTEM ABEND, does not
On Feb 13, 2012, at 06:52, Steve Comstock wrote:
> On 2/13/2012 3:49 AM, Thomas Berg wrote:
>> Why not code: DC X'00' ?
>>
>> (Just a curious amateur in asm)
>
> Well, the following instruction will be on an
> odd boundary, ...
>
Is this even true if the programmer uses PARM=NOALIGN?
But this is
On Mon, 13 Feb 2012 06:52:23 -0700 Steve Comstock
wrote:
:>On 2/13/2012 3:49 AM, Thomas Berg wrote:
:>> Why not code: DC X'00' ?
:>> (Just a curious amateur in asm)
:>Well, the following instruction will be on an
:>odd boundary, for one.
Not unless there is some weird assembler option that al
We have of course been here before.
The idea that a desired USER ABEND is best achieved by triggering a
SYSTEM ABEND that will be minimally confusing, highly unlikely to be
confused with the corresponding real SYSTEM ABEND, does not seem to
want to die.
Why try to trick the system into issuing an
On 2/13/2012 3:49 AM, Thomas Berg wrote:
Why not code: DC X'00' ?
(Just a curious amateur in asm)
Well, the following instruction will be on an
odd boundary, for one. More common, I think:
DC H'0'
Regards,
Thomas Berg
_
Thomas Berg Speciali
Well, it's an extention of my general case:
..DO SOME TEST
..BRC ??,*+2 **ABEND IF THIS OCCURS!
So if I want an "unconditional" S0C1, I do a BRC 15,*+2 aka J *+2. I plan,
someday perhaps, to use this as my "debug entry". I'll have an ESTAEX active.
If I get an S0C1, check for x'0001' at the PSW
On Mon, 13 Feb 2012 12:20:58 +0100 Martin Truebner
wrote:
:>Thomas (or should I say "amateur in asm" ;-)
:>The idea is to produce something that is easy recognisable as "done on
:>purpose" and not to muddy the water more for this "unexpected"
:>situation.
:>I for example always have a EX *,* (o
I have always liked Dave Cole's approach in z/XDC here - he supplies a "#DIE"
macro that places X'00DEAD' in the code followed by identification bytes that
indicate where in the code the #DIE was and optional comments
Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466
But a "DC X'00'" must obviously be "done on purpose" when at a place when
constants/data is not expected ?
At least as much as a "EX *,*" ? (That could be a finger slip.)
Regards,
Thomas Berg
_
Thomas Berg Specialist A M SWEDBANK
> -Ursprun
Thomas (or should I say "amateur in asm" ;-)
The idea is to produce something that is easy recognisable as "done on
purpose" and not to muddy the water more for this "unexpected"
situation.
I for example always have a EX *,* (or an equivalent if there is no
base covering it) after a EXEC CICS RET
Why not code: DC X'00' ?
(Just a curious amateur in asm)
Regards,
Thomas Berg
_
Thomas Berg Specialist A M SWEDBANK
> -Ursprungligt meddelande-
> Från: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] För McKown,
Sorry,
should have been "... less than or equal to 256 ..."
Kind regards
Bernd
Am 13.02.2012 00:08, schrieb Steve Smith:
There seems to be a common misconception that MVC can't move 256 bytes.
It certainly can. It cannot move zero bytes, but that's not much of a
limitation.
On 2/12/2012 17:45
33 matches
Mail list logo
