IBM Mainframe Forum

Hello,

There's something interesting. How do you walk on memory?

Not ensuring the code is using only locations within the process.

These users thanked the author dick scherrer for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:50 am)

If my post implied all the code problems were listed, I'm sorry -- I certianly did not mean that . I looked at the code until I found the first thing that could cause a "crash" (ABEND for professionals) and stopped looking at that point. Based on the first few lines, I'm certain there are plenty of other problems!

The classic method of walking on memory is to define a table with a fixed number of elements, say 10. You then store values in that table past the upper limit -- everything you store after the 10th element (if the limit is 10) will be stored in memory, but not the memory of the table. Do this long enough in many programs, and you'll corrupt the program instructions.

These users thanked the author Robert Sample for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:50 am)

Partway revised:

Your partway was the wrongway anyway

as already somebody told You ...
the register save should precede the setting up of the base register

and as usual You did not care to read the z390 documentation,
You just copied thing without trying to understand

the subentry and the subexit macros ...



so no reason at all to redo what has already been done ( saving the registers and <loading> the base register )

and ... did You notice that the SUMRTN was entered once, but
as usual if You had read the documentation and followed the run time instructions



You would have noticed that both in the console log and in lab6a.log the register 15 contains a nice 0, hence the 0c1

repeat novemtrigillion times

any subroutine using zOS macros must abide the CALL conventions and save/restore properly the registers

when You will have gained more experience You might be stingy to save and restore only the register being used
like I did in the quick and dirty mod I made
but to start with, just follow the normal/best practice of saving and restoring everything

after fixing the obvious I got the correct results



I just made the simple hack of defining a save area for R15
here is the <fixed> thing



now it it the time to stop wasting time creating what You properly define stupid gibberish
and start rereading all the post You have made, trying to understand the answers You were given !

These users thanked the author enrico-sorichetti for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:50 am)

enrico-sorichetti wrote:Your partway was the wrongway anyway

Yeah I misunderstood what the presentation pdf I was using was trying to say. I most likely should have tried harder to RTFM. Anyway, that's helpful, and I'll get back to you if I still have an issue understanding subroutines. After examining (technical) documentation.

That's pretty good! I'd make these changes:No sense putting in mystery hexadecimal values! There is nothing wrong with LA 3,0. In fact since the LA instruction does not alter the condition code and SR does alter the condition code it might be preferred.I prefer to self document. A DS instead of a DC is OK, too, but I generally prefer to initialize storage with something, which, at least in theory, a DS does not do.Here, again I self document and also void mystery hexadecimal vales. Note, too, the use of a significance start code in the last 3 digit group. In real code I'd put all of this on one line, probably continued to a second line, but I can't do this here because of the limited width of a code block.

These users thanked the author steve-myers for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:50 am)

@steve-myers Thanks

Okay - I don't want to act like a cheater so - BAL 15,SUMRTN (branch and link) sends you off to the subroutine (SUMRTN), saving the address of the next instruction in register 15. in the subroutine, register 15 is stored in SAV15, the message is run, then SAV15 is loaded in the register. Some field testing shows SAV15 was used to prevent the message from disrupting what was in register 15, probably because of the nature of the subroutine.

So anyway I'd be happy to read about why that happened to register 15. Surely something to do with the Subentry and Subexit macros. If you'd prefer I read documentation I wouldn't be offended.

Stupid subroutines, they're not like higher level functions/methods... Oh well, my bad for expecting assembler to act like compiled code. An update is below:

So anyway I'd be happy to read about why that happened to register 15. Surely something to do with the Subentry and Subexit macros. If you'd prefer I read documentation I wouldn't be offended.

the subentry and subexit have nothing to do with it ..

R15 is <clobbered> from what happens inside the SUMRTN ...
but that would have been clear if instead of just <copying> a WTO You had taken the time to read the relevant manuals

z/OS V1R10.0 MVS Programming Assembler Services Guide
http://publibz.boulder.ibm.com/cgi-bin/ ... 0523015946
z/OS V1R10.0 MVS Programming Assembler Services Reference Vol 1 (ABEND-HSPSERV)
http://publibz.boulder.ibm.com/cgi-bin/ ... 0522045539
z/OS V1R10.0 MVS Programming Assembler Services Reference Vol 2 (IARR2V-XCTLX)
http://publibz.boulder.ibm.com/cgi-bin/ ... 0601235844

where for each macro is described in detail and You would have noticed - if <You had read it>
the sections

88.1.4 Input Register Information

( irrelevant in this case )
and

88.1.5 Output Register Information


When control returns to the caller, the output registers contain the following values:

Register Contents

0
Used as a work register by the system unless WTO returns code X'20' in register 15. In that case, register 0 contains the number of active WTO buffers for the issuer's address space.
1
Message identification number if the WTO macro completed normally (you can use this number to delete the message when it is no longer needed); otherwise, used as a work register by the system.
2-13
Unchanged.
14
Used as a work register by the system.
15
Return code.
When control returns to the caller, the access registers (ARs) contain:

Register Contents

0-1
Used as work registers by the system
2-13
Unchanged
14-15
Used as work registers by the system
Some callers depend on register contents remaining the same before and after issuing a service. If the system changes the contents of registers on which the caller depends, the caller must save them before issuing the service, and restore them after the system returns control.

so the registers modified by the WTO are 0,1,14,15
that' s the reason I said that the SAV15 hack was a quick and dirty one ...
I DID not want to read the whole program to find the register usage and fixed only the R15 clobbering.

again and again READ THE FRIENDLY MANUALS , if You had done that from the beginning You would have asked many less questions !

These users thanked the author enrico-sorichetti for the post:

RISCCISCInstSet (Mon Nov 12, 2012 4:50 am)