On 12/11/2011 10:38 PM, Lindy Mayfield wrote:
Is this the correct documentation for assembler? Language ref and Programmer's
guide? Doesn't seem right. I wanted to look up info on DSECT (I wanted to
know how to do a redefines), but I don't seem to find any good info on it.
Thanks in advance
On Mon, 12 Dec 2011 05:38:25 +, Lindy Mayfield wrote:
>I wanted to look up info on DSECT (I wanted to know how to
>do a redefines), but I don't seem to find any good info on it.
ORG
--
Tom Marchant
Is this the correct documentation for assembler? Language ref and Programmer's
guide? Doesn't seem right. I wanted to look up info on DSECT (I wanted to
know how to do a redefines), but I don't seem to find any good info on it.
Thanks in advance
Lindy
http://publibz.boulder.ibm.com/cgi-bin/b
On 12/11/2011 8:12 AM, Peter Relson wrote:
Do you think applications have a need for using SAC?
They sure do if they use data spaces. (Even ignoring the fact that
"applications" does not equate to "unauthorized")
As to where to "draw the line", draw it where it makes sense. If the
operating sy
>Do you think applications have a need for using SAC?
They sure do if they use data spaces. (Even ignoring the fact that
"applications" does not equate to "unauthorized")
As to where to "draw the line", draw it where it makes sense. If the
operating system lets an unauthorized program do somethin
Steve,
>> Do you think applications have a need for using SAC?
You could have asked when 64 bit was not available. The answer then:
YES of course. Today: maybe, if the data is still in a dataspace
>> ... a shop where the top manager banned BXLE - he thought
it was too hard to understand!)
Toda
On 12/10/2011 11:41 AM, Steve Comstock wrote:
Wow! I didn't know I wielded such power. :-)
You da Man! :-D
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/
On 12/10/2011 8:36 AM, Edward Jaffe wrote:
On 12/10/2011 4:08 AM, Bernd Oppolzer wrote:
To solve this problem, I ended up with a GET routine for every QSAM dataset,
where the EODAD address is part of the routine. The GET routine looked like
this (from memory, I don't have the sources at hand):
On 12/10/2011 9:44 AM, Martin Truebner wrote:
Once your minimum supported operating system enables use of a particular
semi-privileged instruction, then you can use it just the same as you would any
new macro-based system service provided by that same level of the OS.
Well said
(with the restr
Yup,
But the last time I tried it MVCOS was (much) slower than an EXecuted MVC.
Don't remember how it compared to a MVCL(E). But it xould help out if you might
need to move more than 256 bytes but not more than 4096 bytes.
Fred!
Sent from my iPad
On Dec 10, 2011, at 21:01, "Steve Comstock" w
>> Once your minimum supported operating system enables use of a particular
semi-privileged instruction, then you can use it just the same as you would any
new macro-based system service provided by that same level of the OS.
Well said
(with the restrictions Ed pointed out) I see no reason not to
On 12/10/2011 6:22 AM, Steve Comstock wrote:
Hmmm. Are you advocating use of semiprivileged instructions
in application code then? Or only some of them? Which ones
are 'safe' or 'OK' to use in standard application programs?
Where does one draw the line?
Once your minimum supported operating sys
On 12/10/2011 4:08 AM, Bernd Oppolzer wrote:
To solve this problem, I ended up with a GET routine for every QSAM dataset,
where the EODAD address is part of the routine. The GET routine looked like
this (from memory, I don't have the sources at hand):
GET1 PSTART (R10,R14)start macro for
On 12/10/2011 7:22 AM, Steve Comstock wrote:
On 12/10/2011 7:12 AM, Peter Relson wrote:
I actually disdain using the
linkage stack, for these reasons:
BAKR / PR are included in Chapter 10 of the POO: Control
Instructions, not Chapter 7, General Instructions; they
are semiprivileged instructio
On 12/10/2011 7:12 AM, Peter Relson wrote:
I actually disdain using the
linkage stack, for these reasons:
BAKR / PR are included in Chapter 10 of the POO: Control
Instructions, not Chapter 7, General Instructions; they
are semiprivileged instructions
I do not believe that that reason has mer
>I actually disdain using the
>linkage stack, for these reasons:
>BAKR / PR are included in Chapter 10 of the POO: Control
>Instructions, not Chapter 7, General Instructions; they
>are semiprivileged instructions
I do not believe that that reason has merit.
>but I think the easy way is not alway
Team, I'm currently out of the office. I will return on Monday Dec 19, 2011. If
you need immediate assistance while I’m gone, please contact my manager (Peter
Moir). Otherwise, send me an email message and I will respond when I return.
Thank you, Greg Bowers
Some day I designed a large ASSEMBLER program which needed to
read some QSAM files, and I soon discovered that the out-of-line branches
imposed by the EODAD processing violated the clean structure of the program,
because the input logic of the many files which were read in parallel
was somehow
com
On 12/9/2011 2:13 PM, Edward Jaffe wrote:
On 12/9/2011 11:33 AM, Steve Comstock wrote:
For application programming (granted: there are precious few
applications written in Assembler these days, except by
software product developers), I actually disdain using the
linkage stack, for these reasons
On 12/9/2011 11:33 AM, Steve Comstock wrote:
For application programming (granted: there are precious few
applications written in Assembler these days, except by
software product developers), I actually disdain using the
linkage stack, for these reasons:
Actually, I wasn't talking about the li
On 12/9/2011 10:53 AM, Steve Comstock wrote:
I disagree. Why test a flag after every GET? QSAM essentially
does that for you and branches you to EODAD automatically; if
you find yourself in your EODAD routine you know you're ready
for the next phase of your processing, which might be just
shuttin
On 12/9/2011 11:10 AM, Edward Jaffe wrote:
On 12/9/2011 9:07 AM, Steve Comstock wrote:
Right, so I would argue that the GET approach is more 'traditional'
than the 'traditional approach' you describe: it's been around longer.
I should have said 'typical'. The flaws introduced by older 1960s-e
On 12/9/2011 9:07 AM, Steve Comstock wrote:
Right, so I would argue that the GET approach is more 'traditional'
than the 'traditional approach' you describe: it's been around longer.
I should have said 'typical'. The flaws introduced by older 1960s-era designs
have been corrected in modern imp
On 12/9/2011 9:42 AM, Edward Jaffe wrote:
On 12/9/2011 7:53 AM, Steve Comstock wrote:
I disagree. Why test a flag after every GET? QSAM essentially
does that for you and branches you to EODAD automatically; if
you find yourself in your EODAD routine you know you're ready
for the next phase of yo
On Fri, 9 Dec 2011 10:51:53 -0500, wrote:
>Original Message From: "Joe Owens"
>>Your EODAD routine looks like a potential problem.
>>The access method calls
>>your EODAD inside the get.
>
>That's BIG news to me, since when is that so?
It isn't so.
You can treat your EODAD routine as a subrouti
On 12/9/2011 7:53 AM, Steve Comstock wrote:
I disagree. Why test a flag after every GET? QSAM essentially
does that for you and branches you to EODAD automatically; if
you find yourself in your EODAD routine you know you're ready
for the next phase of your processing, which might be just
shutting
On 12/9/2011 8:20 AM, Joe Owens wrote:
This is a great thread. It is great to see someone enthusiastic about
learning assembler.
Your EODAD routine looks like a potential problem. The access method calls
your EODAD inside the get. Here you would normally set a flag to say EOD
occured and return
Original Message From: "Joe Owens"
Your EODAD routine looks like a potential problem. The access method calls
your EODAD inside the get.
That's BIG news to me, since when is that so?
Andreas F. Geissbuehler
AFG Consultants Inc.
http://www.afgc-inc.com/
This is a great thread. It is great to see someone enthusiastic about
learning assembler.
Your EODAD routine looks like a potential problem. The access method calls
your EODAD inside the get. Here you would normally set a flag to say EOD
occured and return to operating system (BR14), and test this
On 12/9/2011 6:40 AM, Dan Skomsky, PSTI wrote:
Oops. Don't you mean "MVC OUTBUF+1(L'OUTBUFF-1),OUTBUF"? I'm sure you
don't want to zap the byte immediately after OUTBUF. What is "MVC2",
another MACRO?
Yes, as mentioned in this thread.
Why not just code the literal move "MVC OUTBUF,
=(L'OUT
Where does that "Y" come from?
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
Dan
>> -1 missing
Could I say "it ways a test"
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
On Fri, Dec 9, 2011 at 11:50 AM, Martin Truebner wrote:
> Rob,
>
> I felt bad about posting it...it does waste storage under a
> baseregister (which is still in most cases 4K)
Hey, you obviously should not use this when the output field is
seriously larger than the string. I would only do this wh
MBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Martin Truebner
Sent: Friday, December 09, 2011 4:50 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ASM Program to copy a file
Rob,
I felt bad about posting it...it does waste storage under a baseregister
(which is still in most cases 4K)
Don't forget
CLC =C'this is a test',OUTBUF
too.
Clem
Martin Truebner wrote:
Rob,
I felt bad about posting it...it does waste storage under a
baseregister (which is still in most cases 4K)
Much better is the MACRO-way by Ed.J (and some extra code)
like this:
MVI OUTBUF,C' '
Rob,
I felt bad about posting it...it does waste storage under a
baseregister (which is still in most cases 4K)
Much better is the MACRO-way by Ed.J (and some extra code)
like this:
MVI OUTBUF,C' '
MVC OUTBUF+1(L'OUTBUF),OUTBUF
MVC2 OUTBUF,=C'this is a sample'
Wastes
On Fri, Dec 9, 2011 at 9:44 AM, Dougie Lawson wrote:
>>> :>And MVC INOUTBUF,=CL(L'INOUTBUF)='Test record' would have worked as
>>> :>well.
> Hey, that's a neat trick. I wish the folks who taught me assembler
> back in 1981 had shown me that one. But for some odd reason they were
> against using
On 9 December 2011 01:22, Ray Mullins wrote:
> On 2011-12-08 09:43, Binyamin Dissen wrote:
>>
>> On Thu, 8 Dec 2011 17:14:38 +0100 Martin Truebner
>> wrote:
>>
>> :>>> A change to MVC INOUTBUF(11),='Test record' works just fine.
>>
>> :>And MVC INOUTBUF,=CL(L'INOUTBUF)='Test record' would have w
On 2011-12-08 09:43, Binyamin Dissen wrote:
On Thu, 8 Dec 2011 17:14:38 +0100 Martin Truebner
wrote:
:>>> A change to MVC INOUTBUF(11),='Test record' works just fine.
:>And MVC INOUTBUF,=CL(L'INOUTBUF)='Test record' would have worked as
:>well.
Unless INOUTBUF is longer than the literal and
IBM Mainframe Assembler List wrote on
12/08/2011 02:49:14 PM:
> From: Lindy Mayfield
> ... This text was probably written in 1969 or so.
>
> Wonderful how a book last updated in 1984 is still valid today. How
> many MicSoft books and software I've thrown in the trash over the
> years. How mu
OFok4
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Comstock
Sent: Thursday, December 08, 2011 9:25 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ASM Program to copy a file
Ah, but that is specified as OPTC
Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Comstock
Subject: Re: ASM Program to copy a file
Omit the START statement; the CSECT statement does the same thing.
DS0H
Don't need the above; your program is guaranteed to be loaded at an a
On 12/8/2011 12:57, Steve Comstock wrote:
On 12/8/2011 7:14 AM, Lindy Mayfield wrote:
There was a kinda-sorta challenge for me to write the most basic
assembler program to copy a file. Since I am no assembler programmer
by any means, it of course took me some time to get it done. Also I
had no
otaling is ignored.
Gerorge S. Says:
T (watch this one) substitute mode.
===
Thanks so much as always, Steve.
Lindy
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Comstock
Sent: Thursday, December 08, 2011 7:57 PM
To
On Thu, Dec 8, 2011 at 12:57 PM, Steve Comstock wrote:
> ...[ I love this quote, from the PDF version, p. 326 [logical
> page number, 348 physical page number]]:
>
> "It is not the intent of IBM to require extensive education
>to use assembly language programming."--...
Good one Steve
On 12/8/2011 9:57 AM, Steve Comstock wrote:
BAKR R14,0 Save caller's ARs and GPRs
Why do you care about the caller's ARs? First, you are
a main program so the caller is z/OS. Overkill. Why not
use standard save area chaining?
BAKR R14,0 is a standard entry linkage a
e me go to the docs and try to
understand things better.
Lindy
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Comstock
Sent: Thursday, December 08, 2011 7:21 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ASM Program
On 12/8/2011 7:14 AM, Lindy Mayfield wrote:
There was a kinda-sorta challenge for me to write the most basic
assembler program to copy a file. Since I am no assembler programmer
by any means, it of course took me some time to get it done. Also I
had no clue where to start. I'd say all total ab
On Thu, 8 Dec 2011 17:14:38 +0100 Martin Truebner
wrote:
:>>> A change to MVC INOUTBUF(11),='Test record' works just fine.
:>And MVC INOUTBUF,=CL(L'INOUTBUF)='Test record' would have worked as
:>well.
Unless INOUTBUF is longer than the literal and the literal is near the end of
a page.
--
Bin
usually reserved for
subroutines.
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Martin Truebner
Sent: Thursday, December 08, 2011 6:15 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ASM Program to copy a file
Lindy,
here is some
On 12/8/2011 8:14 AM, Martin Truebner wrote:
Much better solution is what (ITIR) Ed J. uses ... a MACRO called MVCSL (or
so) which means MVC in sender length.
I'm surprised you remember this! It was something I accidentally left in a
sample code fragment in a SHARE presentation years ago.
We c
He has RENT specified in the linkedit parms but his program is not reentrant.
--Original Message--
From: Martin Truebner
Sender: IBM Mainframe Assembler List
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
ReplyTo: IBM Mainframe Assembler List
Subject: Re: ASM Program to copy a file
Sent: 8 Dec 2011
Lindy,
>> I don't know what specifically caused the S0C4, you say it was the
>> EODAD address?
No- You moved 80 bytes but had only 11 ...if it is the very end of your
program (likely) this will overlap into something where the hardware
can limit (disallow to see/not there= SOC4)
--
Martin
Pi_c
DD *
ENTRY COPYFILE
NAME COPYFILE(R)
/*EOF
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Martin Truebner
Sent: Thursday, December 08, 2011 6:15 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ASM Program to copy
Lindy,
here is some more
>> 2. Those horrible S0C4's. First one was a S0C4-10, unknown module,
>> and happened on the OPEN. How could I have debugged this? The
>> problem that I found from reading (yes reading the docs, I do) the
>> docs carefully, was that DCB's have to be in 24 bit mode st
There was a kinda-sorta challenge for me to write the most basic assembler
program to copy a file. Since I am no assembler programmer by any means, it of
course took me some time to get it done. Also I had no clue where to start.
I'd say all total about 5 or 6 hours to get it finished. This
56 matches
Mail list logo
