On 2014-02-20, at 20:50, John Gilmore wrote:
> The appropriate distinction not bwteeen what may appear in macro and
> outside them. It is that between the syntax of the macro language and
> 'vanilla' assembly language. This is important because macro-language
> statements can appear outside macr
The appropriate distinction not bwteeen what may appear in macro and
outside them. It is that between the syntax of the macro language and
'vanilla' assembly language. This is important because macro-language
statements can appear outside macro definitions, i.e., in open code.
The construct
&tx
This was patch week. Did Windows 8.1 update default mail settings to a "better"
encoding :)
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of Scott Ford
> Sent: Thursday, February 20, 2014 10:06 PM
> To: ASSEMBLER-LIST@LISTS
Windows 8.1 x64 , Windows Mail and I don't cant change anything I am aware of.
From: Walt Farrell
Sent: Thursday, February 20, 2014 4:02 PM
To: IBM Mainframe Assembler List
On Thu, 20 Feb 2014 17:05:12 +, Scott Ford wrote:
>Z3V5cyBpcyB0aGlzIG1lc3NhZ2UgYmV0dGVyIGFuZCBub3
Scott's messages from his iPad look OK on the listserv. The others look OK in
Outlook, but not on the listserv.
So, Scott, what eMail client are you using when you aren't sending from your
iPad?
David de Jongh
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIS
Since I brought it up, I've asked our systems folks to submit a RFE for
this.
I had to submit one earlier this week for the missing extended mnemonics
for the [N] Z/M/P/O conditions on the LOC[G] and STOC[G] instructions!
Currently, only [N] E/H/L conditions are supported.
Robert Ngan
CSC Financia
On Thu, 20 Feb 2014 17:05:12 +, Scott Ford wrote:
>Z3V5cyBpcyB0aGlzIG1lc3NhZ2UgYmV0dGVyIGFuZCBub3QgYmFzZS02NC1lbmNvZGVkID8/Pw0K
>DQpQbGVhc2UgbGV0IG1lIGtub3csLCwNCg0KDQpSZWdhcmRzLA0KDQpTY290dA==
Sorry, Scott, still BASE-64 via the web interface (and, presumably, in the
archive). The one over
On Thu, 20 Feb 2014 14:01:28 +, Blaicher, Christopher Y.
wrote:
>FYI - I am running OUTLOOK 2013 on a windows 7 system and have no problem
with Scott's messages.
The issue is with viewing his messages via the web interface to the list, or
via the archives of the list, Chris. I'm sure that (m
Gil asked:
>When is an RFE necessary? Who submitted the RFE to add long
>displacement capability other than in USINGs? Who submitted
>the RFE to add z196 capability to HLASM? Etc.
Support for z196 and long displacements came from IBM Processor
Architecture, as do requirements for supporting new
On 2014-02-20 16:34, John Ehrman wrote:
> Gil noted that I wrote:
>>
>> Addressability of the base location is a requirement for Dependent
> USINGs.
>>
> and replied:
>> Who made that rule? Why? Can it be appealed? And why
>> addressability with 12-bit displacement (you neglected or
>> deliberat
Gil noted that I wrote:
>
> Addressability of the base location is a requirement for Dependent
USINGs.
>
and replied:
> Who made that rule? Why? Can it be appealed? And why
> addressability with 12-bit displacement (you neglected or
> deliberately omitted to say that), rather than one of the
> l
On 2014-02-20 16:06, John Ehrman wrote:
>
> Addressability of the base location is a requirement for Dependent USINGs.
>
Who made that rule? Why? Can it be appealed? And why
addressability with 12-bit displacement (you neglected or
deliberately omitted to say that), rather than one of the
longer
Gil asked why an algebraically equivalent form won't work:
It's because AREA-8192 (in Jonathan Scott's example) is addressable by an
existing base register; but AREA-10 (in your example) is not.
Addressability of the base location is a requirement for Dependent USINGs.
On 2014-02-20 15:11, John McKown wrote:
>
> That's why I really like FLOWASM. Let it worry about the idiosyncrasies of
> the HLASM parser's love of 80 column cards.
>
Are there EDIT macros to UNFLOW on entry for easy editing,
and REFLOW at SAVE to be able to assemble?
(Of course, this is made need
On 2014-02-20 12:20, Jonathan Scott wrote:
> Ref: Your note of Thu, 20 Feb 2014 12:54:15 -0600
>
> As a workaround for dependent USING outside the 4K limit, just
> subtract the same amount from the USING origin and the base address
> to bring it back into range, for example:
>
>USING AREA-
On Thu, Feb 20, 2014 at 3:59 PM, Paul Gilmartin wrote:
> On 2014-02-20 14:38, Ed Jaffe wrote:
> > On 2/20/2014 12:53 PM, Robert Ngan wrote:
> >> It'd be nice if macros and instruction operands were handled the same
> way,
> >> I don't like splitting operand names across lines as it makes searching
Based on the example code from my previous topic, I tried:
LA2,0+X
Fld2
and it works!
Robert Ngan
CSC Financial Services Group
IBM Mainframe Assembler List wrote on
2014/02/20 15:38:16:
> From: Ed Jaffe
> To: AS
I have coded another trick immediately after the one shown below. I
relies on the fact that the argument immediately after the opcode/macro
does not have to be in any particular column. Not pretty but it works.
> From: Ed Jaffe
> On 2/20/2014 12:53 PM, Robert Ngan wrote:
> > It'd be nice if mac
On 2014-02-20 14:38, Ed Jaffe wrote:
> On 2/20/2014 12:53 PM, Robert Ngan wrote:
>> It'd be nice if macros and instruction operands were handled the same way,
>> I don't like splitting operand names across lines as it makes searching for
>> them more difficult so I use zeros as a pad character, e.g
On 20 February 2014 15:39, Frank M. Ramaekers wrote:
> So you have to find a way to keep everything (in an instruction) on a
> single line?
No - not at all. It's just that the instruction and operands can't
contain unquoted blanks, so you have to run it all the way to (by
default) column 71, and
The IBMer that created that field name should be shot, quartered, then
rung up the pole.
Tony Thigpen
-Original Message -
From: Tony Thigpen
Sent: 02/20/2014 03:56 PM
Yep.
QVIS_L EQU L'QVSIMGLOGICALPARTITIONNAME
MVC 0(QVIS_L,R4,QVSIMGLOGICALPARTITIONNAME
Of course, you
On 2/20/2014 12:53 PM, Robert Ngan wrote:
It'd be nice if macros and instruction operands were handled the same way,
I don't like splitting operand names across lines as it makes searching for
them more difficult so I use zeros as a pad character, e.g.
MVC 0(L'QVSIMGLOGICALPARTITIONN
On 2/20/2014 12:39 PM, Frank M. Ramaekers wrote:
So you have to find a way to keep everything (in an instruction) on a
single line?
Instructions can span multiple lines, but they cannot have embedded
whitespace. You must write your operand(s) all the way to column 71,
place the continuation cha
Learn something new every day.
Thanks all,
Frank M. Ramaekers Jr.
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of Tony Thigpen
> Sent: Thursday, February 20, 2014 2:56 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: R
Yep.
QVIS_L EQU L'QVSIMGLOGICALPARTITIONNAME
MVC 0(QVIS_L,R4,QVSIMGLOGICALPARTITIONNAME
Of course, you can always play the "it will never change" card with:
MVC 0(8,R4,QVSIMGLOGICALPARTITIONNAME
knowing that changing the length of this field will require an act of god.
Ton
It'd be nice if macros and instruction operands were handled the same way,
I don't like splitting operand names across lines as it makes searching for
them more difficult so I use zeros as a pad character, e.g.
MVC 0(L'QVSIMGLOGICALPARTITIONNAME,R4),+*
On 2014-02-20 13:39, Frank M. Ramaekers wrote:
> So you have to find a way to keep everything (in an instruction) on a
> single line?
>
FLOWASM?
-- gil
So you have to find a way to keep everything (in an instruction) on a
single line?
Frank M. Ramaekers Jr.
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of Ed Jaffe
> Sent: Thursday, February 20, 2014 2:26 PM
> To: ASSEMBLE
I tried to send it with a COURIER NEW font, but it appeared to have gotten
stripped.
* - column 72
Next line starts in 16
Frank M. Ramaekers Jr.
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of John McKown
> Sent: Thurs
if you had two base regs for Area1, then Fld4 would already be addressable and
the dependent using would know where to start the definition. Obviously you
would also need to load the second base reg for it to actually work at
execution time.
However, I strongly suspect that using long displace
On Thu, Feb 20, 2014 at 2:08 PM, Frank M. Ramaekers
wrote:
> ...what am I doing wrong here:
>
>
>
> 000728 0 0 8032 MVC
> 0(L'QVSIMGLOGICALPARTITIONNAME,R4), *
>
>
> QVSIMGLOGICALPARTITIONNAMEMove out the LPAR name
>
> ** ASMA074E Illegal sy
On 2/20/2014 12:08 PM, Frank M. Ramaekers wrote:
...what am I doing wrong here:
000728 0 0 8032 MVC
0(L'QVSIMGLOGICALPARTITIONNAME,R4), *
QVSIMGLOGICALPARTITIONNAMEMove out the LPAR name
** ASMA074E Illegal syntax in expression -
On
On 2/20/2014 11:54 AM, Paul Gilmartin wrote:
How long has the hardware provided long displacements?
Going on eleven years. :(
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
...what am I doing wrong here:
000728 0 0 8032 MVC
0(L'QVSIMGLOGICALPARTITIONNAME,R4), *
QVSIMGLOGICALPARTITIONNAMEMove out the LPAR name
** ASMA074E Illegal syntax in expression -
Frank M. Ramaekers Jr. | Systems Programmer
HLASM 1.6 (PTF UK82594)
Robert Ngan
CSC Financial Services Group
IBM Mainframe Assembler List wrote on
2014/02/20 13:54:53:
> From: Paul Gilmartin
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 2014/02/20 13:58
> Subject: Re: Error with dependant USING beyond 4096 bytes
> Sent by: IBM Mainframe
On 2014-02-20 12:41, Robert Ngan wrote:
> OK, that worked, but... we shouldn't need to do that!
>
Yup.
How long has the hardware provided long displacements?
How much longer can HLASM remain ignorant of them?
What does the "H" in HLASM stand for?
(But what assembler release were you using?)
--
OK, that worked, but... we shouldn't need to do that!
Robert Ngan
CSC Financial Services Group
IBM Mainframe Assembler List wrote on
2014/02/20 13:20:27:
> From: Jonathan Scott
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 2014/02/20 13:31
> Subject: Re: Error with dependant USING beyond 4096
I'm using long displacement instructions, the assembler should accept the
USING and only issue an error if I attempt to use a 12-bit displacement
instruction against a field beyond 4K.
Robert Ngan
CSC financial Service Group
IBM Mainframe Assembler List wrote on
2014/02/20 13:08:45:
> From: "Fa
Ref: Your note of Thu, 20 Feb 2014 12:54:15 -0600
As a workaround for dependent USING outside the 4K limit, just
subtract the same amount from the USING origin and the base address
to bring it back into range, for example:
USING AREA-8192,BASE-8192
(When I started to reply to this, it se
Hi Robert,
Here’s the output from the Dignus assembler for your example:
Dignus Assembler Option Summary
Page1
Ref: Your note of Wed, 15 Jan 2014 10:36:00 -0700
Paul Gilmartin wrote:
> On 2014-01-15, at 01:43, Jonathan Scott wrote:
> >
> > The ASMALTAS table used for TRANSLATE(AS) converts code page 037
> > to code page 819 (ISO 8859-1), using a full 256-byte mapping.
> >
> And with a private translate ta
As you have coded it, FLD4 is outside of the USING for Area1 (Fld4 starts at
the 6K boundary). The USING for Area1 only covers the first 4K, so you would
need a second base register in the USING for Area1 if you want to use Fld4 as
the base for Area2.
USING Area2,Fld2 should work just fine, bi
I'm trying to use a dependant USING for an area beyond 4096 bytes from the
base register, but the USING is generating a "ASMA307E No active USING for
operand" error.
The Language Reference manual states for "Dependant USING" on page 227:
address
is a simply relocatable expression that represents
I keep hoping to find a replacement, but I can find nothing with the facilities
of Eudora. So, I plod on ...
Michael
At 07:15 PM 2/20/2014 +, you wrote:
>Content-Transfer-Encoding: base64Michael:
>
>
>I have used Eudora in awhile, wow ..thank you
>
>
>Regards,
>
>Scott
>
>
>
>
>
>
>
>
>
>
>
Michael:
I have used Eudora in awhile, wow ..thank you
Regards,
Scott
From: Michael Stack
Sent: Thursday, February 20, 2014 7:46 AM
To: IBM Mainframe Assembler List
Scott, here is how it looks from Eudora (which hasn't had maintenance for many
years, and has no ide
Scott, here is how it looks from Eudora (which hasn't had maintenance for many
years, and has no idea how to handle some code pages):
At 05:05 PM 2/20/2014 +, you wrote:
>Content-Transfer-Encoding: base64guys is this message better and not
>base-64-encoded ?Â
>Please let me know,,,
>
>
>Reg
Thanks , David
Sent from Windows Mail
From: David de Jongh
Sent: Thursday, February 20, 2014 7:22 AM
To: IBM Mainframe Assembler List
I've had no problem with any of your messages. Outlook 2010, Win7 Pro
64-bit. Verizon.net.
-Original Message-
From: IBM Mainfr
I've had no problem with any of your messages. Outlook 2010, Win7 Pro
64-bit. Verizon.net.
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Scott Ford
Sent: Thursday, February 20, 2014 11:05 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
On 2014-02-20, at 07:01, Blaicher, Christopher Y. wrote:
> FYI - I am running OUTLOOK 2013 on a windows 7 system and have no problem
> with Scott's messages.
>
And I have no problem reading them with Thunderbird. But the
problem clearly appears when reading them from the web site.
Even the Subje
guys is this message better and not base-64-encoded ???
Please let me know,,,
Regards,
Scott
FYI - I am running OUTLOOK 2013 on a windows 7 system and have no problem with
Scott's messages.
Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260 | M: 512-627-3803
E: cblaic...@syncsort.com
-O
Something changed, Scott, in the way you're sending your messages. The ones
you sent to this list on "Tue, 18 Feb 2014 11:35:15 -0500" amd "Tue, 18 Feb
2014 11:51:23 -0500" were just fine. But starting with the one at "Wed, 19
Feb 2014 18:58:19 +" they're garbled, and Base-64 encoded due to UTF
52 matches
Mail list logo
