On 12/8/2011 11:39 AM, Lindy Mayfield wrote:
I tried to take out the extraneous stuff from the DCB. I got this:
DCBIN1 DCB DDNAME=INPUT,EODAD=EOF,MACRF=GM,DSORG=PS
===
Why do I care about the caller's AR's? I copied the preamble from a
properly written program that went briefly into supervisor mode. Otherwise, I
normally don't.
[snip - to get posting under 250 lines]
===
I of course do know that the docs have to assume a certain level of knowledge,
otherwise where to start? That's only fair. At my level, since I have to
create my own challenges, I cannot expect anything other than to learn it all
myself, and of course with help from my friends. And even with no friends, I
can still learn on my own.
Back when I started, I remember, I was so excited when I found out there was
documentation! They kept it on a table in the room near where the "older"
smokers sat, so I didn't go in there very often. And in the middle of a pile of
printouts I didn't notice such stuff. When I asked specifically about such-and-such doc
I was told, documentation is expensive.
Mostly at first I learned 80+ยด% from reading existing code, and about 15% from
a more senior person. In my case a great guy who didn't know a lot about
facts, but could really get the job done. He was a good consultant. Oh, and
he got good and stoned during lunch every day. This was about 1988 or so.
Unnecessary crap where it shouldn't be is/was one thing that tripped me up
quite often. How many times I copied subroutines that I didn't use. Lots.
===
DFSMS, Chapter 5 - Been in front of me the whole day. :-)
===
AH! It was where my program was loaded that was the problem with the DCB's.
Ok, that makes sense. I was wondering, how can I put my DCB's into 24 bit
storage, but have my program run in 31 or 64 bit...
http://www.trainersfriend.com/General_content/Book_site.htm#Assembler-3
I am assuming here based on my limited knowledge, and most of what I read
today: I would somehow put just the DCB's below, one way, perhaps, by using
STORAGE OBTAIN LOC=BELOW and then using the DCB MF=L macro format. There is
some more wizardry there I think, perhaps using USING's or some such.
Now, that is just from my head. And only because I looked at it for a long
time today.
===
And as far as coding reentrantly:
http://www.trainersfriend.com/General_content/Book_site.htm#Assembler-2
Perhaps someone will know more why it should be watched, but this I see in the
docs:
T
requests the user totaling function. If this function is requested, EXLST
should specify the address of an exit list that includes a totaling entry. T
cannot be specified for a SYSIN or SYSOUT data set.
User totaling can be specified for only sequential data sets that are not
extended format data sets. If specified for a partitioned data set, a PDSE, an
extended format data set, or a UNIX file, user totaling is ignored.
Gerorge S. Says:
T (watch this one) substitute mode.
Ah, but that is specified as OPTCD=T, your post said MF=T and I couldn't
find that.
===
Thanks so much as always, Steve.
You're welcome.
Lindy
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On
Behalf Of Steve Comstock
Subject: Re: ASM Program to copy a file
Omit the START statement; the CSECT statement does the same thing.
DS 0H
Don't need the above; your program is guaranteed to be loaded at an address on
a doubleword boundary at the least
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?
LR R12,R15 Set up 1st base register
USING COPYFILE,R12 and inform assembler
OPEN (DCBIN1,(INPUT),DCBOUT1,(OUTPUT))
LOOP DS 0H
GET DCBIN1,INOUTBUF
PUT DCBOUT1,INOUTBUF
B LOOP
EOF DS 0H no more records
CLOSE (DCBIN1,,DCBOUT1)
XR 15,15
PR ,
DCBIN1 DCB BLKSIZE=80,DDNAME=INPUT,RECFM=FB,LRECL=80,DSORG=PS, X
EODAD=EOF,MACRF=GM
For input files, if the file is standard labeled tape or disk, or even SYSIN,
you don't need BLKSIZE, RECFM, or LRECL
DCBOUT1 DCB BLKSIZE=80,DDNAME=OUTPUT,RECFM=FB,LRECL=80,DSORG=PS, X
MACRF=PM
You code RECFM=FB, so you should block your records up for performance; set
BLKSIZE as some multiple of LRECL up to
32760
Although if you are writing to SYSOUT, unblocked is fine since JES will block
it for you anyway; in that case, probably better to code RECFM=F
INOUTBUF DS CL80 Input/Output Storage Area
END ,
Notes:
1. That EODAD is nice. As a matter of fact, this looks strangely a lot like a
Cobol program.
I can almost see where Grace got her inspiration.
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 storage. Whoops.
Where (and what kind of) in the dump would show that information?
Not clear here. The dump will not show you that DCBs have to be in 24-bit
storage. That piece of information comes from the docs:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/EZ2ZO213
DFSMS Using Data Sets SC26-7410-11 (the z/OS 1.13 version)
[ 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."
around this place in the doc, there is an extensive discussion
with samples
DFSMS Macro Instructions for Data Sets SC26-7408-10 (the z/OS 1.13 version)
starting in Chapter 5, non-VSAM data sets
The dump will show where your module is loaded, and since your DCBs are coded
in your module, your DCBs will be there; it the load address of your module
starts with x'00' or x'80', you are in 24-bit storage; otherwise, you are in
31-bit storage.
3. A S0C4-11 because I coded an MVC incorrectly. I coded this:
MVC INOUTBUF(80),=C'Test record'
INOUTBUF DS CL80
A change to MVC INOUTBUF(11),='Test record' works just fine.
I cheated on this one, too. I wasn't able to tell the problem in the
dump.
The dump told me it was the MVC instruction that was wrong, so I just
guessed that it was because the MVC wasn't correct.
Right. The default length for MVC is the length of the first operand, the
target. So you were moving 80 bytes from your literal pool, but the literal is
only 11 bytes; apparently somewhere after the 11 byte literal your load module
ended near a page boundary, and when you tried to access the bytes on the next
page the hardware found that page was not assigned to you.
4. The MACRF options need to be correct, but the assembler warned me
about those. The docs showed all the options, not just QSAM, so
I got them mixed up a little.
The Macro instruction doc provides separate DCB parameter lists for each
organization (BDAM, BISAM, BPAM, BSAM, QISAM, QSAM) so you have to pay
attention there, and also to realize that you are using QSAM. So the doc
assumes a lot already, on the part of the reader.
And I still need to know what MF=T means. The book just says "watch this one."
Well, the IBM book doesn't mention that parameter at all.
I guess in 1969, that was enough.
There are other resources available.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
