An accumulation of replies to multiple posts for this threat.
1.
In a message dated 8/24/2008 10:54:51 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>How do you guys learn this stuff? So well? I mean, it's not like
something they teach you in mainframe school, is it?
We go to SHARE, where we share things, like knowledge, code, helpful hints,
pitfalls to watch out for, sources of knowledge, doc, etc. etc.
We contribute to and study others' contributions to common sources of
helpful code, like the CBT tape.
But most importantly, we all go back in time 30 or 40 years and start
working with IBM operating systems when IBM mainframes were the dominant force
and
there were no PCs or other such Toys-R-Us software [IMHO] to distract us. It
takes a long time to learn all this stuff, even when we have lots of help
from helpful colleagues.
Also back in those Jurassic days there were IBM educational classes, and
then later also Amdahl-taught classes, in how all this stuff works. E.g., I
attended a 2-week Amdahl class in MVS/XA operating system internals in 1985.
I
don't think such classes are available anywhere anymore unless you work for
IBM, and they will send you to all the internal classes you need to work on
whatever it is they hired to work on.
2.
>There's a tiny bit of setup required that the docs either don't mention,
or I didn't see it.
DROP
SRB_ROUTINE DS 0H
USING *,R6
LR R6,R15
The way to debug your own code on your own, with no help from IBM-MAIN, with
your next problem like this is to start with the first instruction in your
SRB routine, find somewhere in the dump or figure out somehow what must have
been in R15 when the SRB code started to execute (some doc somewhere says that
upon entry to an SRB routine R15 contains the address of the code to be
executed), then simulate with pencil and paper the execution of each
instruction
by looking NOT at the instruction (e.g., B SOMEWHERE) but rather at the
assembled object code on the extreme left of each line of the Assembly output.
E.g, if it is a B instruction, then add the contents of what you know (or
believe) to be in the base register of that instruction to the assembled
displacement field in the B instruction, then subtract from that new address
the
value that was in R15 upon entry. This will give you the offset in your
assembled code where you branched to next. If that new next instruction is
not in
your code, then you know you have your base register incorrectly set or else
the USING is wrong upon which the assembly was based (those are the two most
likely reasons).
I suspect your code was assembled without errors (thus letting you assume it
would also execute without error), you moved/copied some of it into the CSA
location you had just gotmained, and the assembled offsets were all wrong for
the new location of the code. You can start such an "independent" piece of
code off with one of the following, e.g.
USING *,R15
blah blah
- or -
BALR R15,0
USING *,R15
blah blah
The first case assumes that some other code, like maybe the operating
system, has correctly loaded R15 with the address at which this code is found
in
storage. The second case does not assume that, and initializes R15 so that
the
following displacements will be correct when the code executes regardless of
where it is located in storage. This is an example of self-relocating code.
3.
Someone else, not Lindey, wrote:
>What are you doing to save and restore the registers that you get when your
code gets control? don't you have to have an R14 to return to, when your
SRB routine is done?
You can save anything you want upon entry to your SRB code so you can later
study what was in the various registers if you want, but you don't have to
save and restore anything in an SRB routine when you exit at the end. When
you
are finished, all you have to do is to arrive somehow at the one instruction
in the dispatcher where SRBs are supposed to return to. One way to find it
is this:
L Rx,CVTPTR Get address of
CVT
L Rx,CVTSRBRT-CVTMAP(,Rx) Get Dispatcher's return
address
BSM 0,Rx Return to the
Dispatcher
where x can be any general purpose register except 0
....
CVT DSECT=YES Get CVT DSECT mapping
It may be that R14 contains this address upon entry to the SRB code, and I
would assume so, but I have never coded an SRB to return that way. I have
always used the CVT pointer to the SRB return address within the Dispatcher,
and
that has always worked. I use this technique because I copied some working
code once from someone else's debugged SRB, and that's the way he did it.
And speaking of saving things upon entry, be careful where you try to save
them. Nothing is as it appears, either in politics or inside computers.
4.
>Which means my primary address space needs to wait for the SRB to
finish, correct?
Not necessarily. In the general case, it depends on what your SRB is
intended to do, what your main code is doing next, and if there really needs to
be
any communication back from the SRB. In this specific case, your SRB code is
snooping in another address space and you want it to return data to your
main code, so your main code will need some mechanism to know when the SRB is
done and has good stuff to return. A WAIT is one way, and in that case the
SRB
can do a POST. But do not code the POST in such a way that it assembles
with the evil SVC instruction (evil when in SRB mode). You will have to do a
branch-entry type of POST. And make sure your SRB is putting its return data
in some storage somewhere that your main code knows how to find. One way to
do that is via the parameter you pass when doing the IEAMSCHD.
Bill Fairchild
Rocket Software
**************It's only a deal if it's where you want to go. Find your travel
deal here.
(http://information.travel.aol.com/deals?ncid=aoltrv00050000000047)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
