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 about 5 or 6 hours to
get it finished. This included reading docs, books, etc., coding and
debugging. And false starts.
You can imagine my immediate frustration when I went off into the EXCP
world (by accident). Then I cheated a little bit and had a peek at
George Struble's _Assembler Language Programming for The IBM System/370 Family_.
The 3rd edition printed 1984, 1st in 1964.
Then I found myself in the QSAM arena, and after that it was quite easy.
Here is my PGM and the two biggest problems I had:
COPYFILE START 0
YREGS
COPYFILE CSECT ,
COPYFILE AMODE 24
COPYFILE RMODE 24
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
