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.
I've so far made it a habit of starting and ending like this. One day I'll
learn macro, though at this point in my life it feels like James Joyce.
BAKR 14,0
LR my-base-whatever,R15
USING etc
... ... ...
PR ,
===
Block size, etc, I didn't care about, because the idea of this exercise came
from a comment about an interview of a potential assembler programmer: Write
an assembly program on the white board there to copy one file to the next. I
wrote a few Rexx functions, but never any standard print/punch IO. QSAM, or
anything else.
===
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...
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.
===
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.
===
Thanks so much as always, Steve.
Lindy
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On
Behalf Of Steve Comstock
Sent: Thursday, December 08, 2011 7:57 PM
To: [email protected]
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
