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 +0000 Michael Knigge > <michael.kni...@set.de> > 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 <bdis...@dissensoftware.com> > 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-5637 Cary, NC 27513 ---------------------------------------------------------------------- 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
