Don,
thanks for the hints. I already did all this - to keep the ASM part as small as
possible I allocated all the stuff I need in the C part using __malloc31() and
passed the pointers to the ASM module. Regarding the Save Area - I guess R13
does not have to point to a SA when invoking a SVC, right?!? At least I didn't
noticed anything about that in the documentation to OUTADD (which invokes SVC
109).
Bye,
Michael
Mit freundlichen Grüßen
Michael Knigge
Software Engineer
SET GmbH
Lister Straße 15
30163 Hannover
phone: +49 511 39780-23
fax: +49 511 39780-65
www.set.de
michael.kni...@set.de
Handelsregister: HRB52778 Amtsgericht Hannover
Geschäftsführer: Till Dammermann, Dr. Bernd Huber
Anstehende Termine:
POSY-OutputForum, 4. und 5. November 2015 in Hannover
Weitere Informationen finden Sie auf unserer Homepage...
-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag
von Don Poitras
Gesendet: Montag, 12. Oktober 2015 14:12
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: Invoke AMODE31-only Code from AMODE64
Michael,
There are some other considerations. If the routine requires a save area and
you are running XPLINK, you need to allocate 72 bytes below the bar and point
R13 to it. Also, any parms passed to the routine must be below the bar. Any
parms that contain pointers used by the routine must also be below the bar,
etc. etc. LE provides __malloc31() to get "middle" memory.
In article <9822352a8a50b84aba12bde56fcda26068953...@mail01.intranet.set.de>
you wrote:
> Binyamin,
> I guess I was lost in the woods of IBM manuals. When I started using Google
> to find the right manual I just came across some weired (at least to me)
> Branch-Statements that should be using when crossing AMODEs.
> Just after I've read your reply I googled again and just found the
> instructions you've mentioned. I've just updated my code and currently it
> looks like everything is working as I would expect... But I've just finished
> my first little isolated test
> So far thank you for your fast and helpful reply
> Bye,
> Michael
> Mit freundlichen Gr??en
> Michael Knigge
> Software Engineer
> SET GmbH
> Lister Stra?e 15
> 30163 Hannover
> phone: +49 511 39780-23
> fax: +49 511 39780-65
> www.set.de
> michael.kni...@set.de
> Handelsregister: HRB52778 Amtsgericht Hannover
> Gesch?ftsf?hrer: Till Dammermann, Dr. Bernd Huber
> Anstehende Termine:
> POSY-OutputForum, 4. und 5. November 2015 in Hannover
> Weitere Informationen finden Sie auf unserer Homepage...
> -Urspr?ngliche Nachricht-
> Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> Im Auftrag von Binyamin Dissen
> Gesendet: Montag, 12. Oktober 2015 10:30
> An: IBM-MAIN@LISTSERV.UA.EDU
> Betreff: Re: Invoke AMODE31-only Code from AMODE64
> I do not really understand your question.
> If your code is running below the bar and the data items required for the
> service are below the bar, the machine instruction SAM31 will change the
> amode to 31 bit and the machine instruction SAM64 will set 64 bit amode,.
> On Mon, 12 Oct 2015 08:15:15 + Michael Knigge
>
> wrote:
> :>is it possible to invoke AMODE31-only code from an AMODE64 module?
> :>To be more detailed: I?m running in USS (with XPLINK) and I need to call
> several System services that are known to not support AMODE64, in my case
> SWAREQ and OUTADD.
> :>I know that I could write a AMODE31 load module, put it in a MVS load
> library, load it with the C function fetch() (which supports AMODE switching)
> and jump right into the module.
> :>But I?d like to remain in USS only. So?. Is it possible to do an
> ?AMODE-switch? in pure assembler without using some load modules from the MVS
> world? I?ve read some manuals over the weekend but I?m more confused than I
> was before reading the manuals (even XPLINK is new to me and the manuals are
> pretty confusing)?.
> --
> Binyamin Dissen
> http://www.dissensoftware.com
> Director, Dissen Software, Bar & Grill - Israel
> Should you use the mailblocks package and expect a response from me, you
> should preauthorize the dissensoftware.com domain.
> I very rarely bother responding to challenge/response systems, especially
> those from irresponsible companies.
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
sas...@sas.com (919) 531-5637Cary, NC 27513
--
For IBM-MAIN subscribe / signoff /