Re: Cobol and Hiperspace (was 64-bit C code fetching IGGCSI00)
You can access hiperspaces in COBOL using the MVS Callable Services for HLLs Window Services https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieac100/ws.htm. There are code examples. On 15/01/2019 2:58 am, scott Ford wrote: Peter: My typos ..sorry the question was in regard to a Cobol program creating and then referencing Hiperspaces. You answer was what I thought, so thank you. Scott On Mon, Jan 14, 2019 at 12:59 PM Peter Relson wrote: So how does a Cobol Pgm , 31bit address say a Hiperspace ? I assume an interface program units AR registers , etc., am I correct ? I have don’t this want to... I could not parse this. What were you trying to ask? Hiperspaces are not directly referenced. You use services to put data in and get data out. And then you reference the buffer you identified, which is in your address space. So aside from invoking the hiperspace services themselves (and dspserv to create/delete the hiperspace), there's nothing special related to Cobol (or any other language). HSPSERV supports only AMODE 31 invocation. Peter Relson z/OS Core Technology Design -- 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
Re: Cobol and Hiperspace (was 64-bit C code fetching IGGCSI00)
Peter: My typos ..sorry the question was in regard to a Cobol program creating and then referencing Hiperspaces. You answer was what I thought, so thank you. Scott On Mon, Jan 14, 2019 at 12:59 PM Peter Relson wrote: > > > So how does a Cobol Pgm , 31bit address say a Hiperspace ? > > I assume an interface program units AR registers , etc., am I correct ? > > I have don’t this want to... > > > I could not parse this. What were you trying to ask? > > Hiperspaces are not directly referenced. You use services to put data in > and get data out. And then you reference the buffer you identified, which > is in your address space. So aside from invoking the hiperspace services > themselves (and dspserv to create/delete the hiperspace), there's nothing > special related to Cobol (or any other language). > > HSPSERV supports only AMODE 31 invocation. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *IDMWORKS * Scott Ford z/OS Dev. “By elevating a friend or Collegue you elevate yourself, by demeaning a friend or collegue you demean yourself” www.idmworks.com scott.f...@idmworks.com Blog: www.idmworks.com/blog *The information contained in this email message and any attachment may be privileged, confidential, proprietary or otherwise protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this message and any attachment is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and permanently delete it from your computer and destroy any printout thereof.* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol and Hiperspace (was 64-bit C code fetching IGGCSI00)
> So how does a Cobol Pgm , 31bit address say a Hiperspace ? > I assume an interface program units AR registers , etc., am I correct ? > I have don’t this want to... I could not parse this. What were you trying to ask? Hiperspaces are not directly referenced. You use services to put data in and get data out. And then you reference the buffer you identified, which is in your address space. So aside from invoking the hiperspace services themselves (and dspserv to create/delete the hiperspace), there's nothing special related to Cobol (or any other language). HSPSERV supports only AMODE 31 invocation. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
Sorry for the typos.. should read Cobol program , I would like to do this. Regards, Scott On Fri, Jan 4, 2019 at 4:19 PM scott Ford wrote: > Peter, > > So how does a Cobol Pam , 31bit address say a Hiperspace ? > I assume an interface program units AR registers , etc., am I correct ? > I have don’t this want to... > > Scott > IDMWORKS > > On Fri, Jan 4, 2019 at 8:46 AM Peter Relson wrote: > >> From the LE team: >> >> fetch() will indeed reject loading load module of another AMODE. >> >> This is related to the fact that LE will not only load the module into >> storage (with the LOAD macro) but will also manage some control blocks >> and >> data for the module, such as the load list table, the WSA and >> fetch-specific control blocks (FECB) etc, in order to make the module >> accessible to the current LE application. >> >> As someone suggested, you could add an assembler routine (or possibly >> inlined assembler) to manage that module instead of LE's managing the >> module >> >> Peter Relson >> z/OS Core Technology Design >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > -- > Scott Ford > IDMWORKS > z/OS Development > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
Peter, So how does a Cobol Pam , 31bit address say a Hiperspace ? I assume an interface program units AR registers , etc., am I correct ? I have don’t this want to... Scott IDMWORKS On Fri, Jan 4, 2019 at 8:46 AM Peter Relson wrote: > From the LE team: > > fetch() will indeed reject loading load module of another AMODE. > > This is related to the fact that LE will not only load the module into > storage (with the LOAD macro) but will also manage some control blocks and > data for the module, such as the load list table, the WSA and > fetch-specific control blocks (FECB) etc, in order to make the module > accessible to the current LE application. > > As someone suggested, you could add an assembler routine (or possibly > inlined assembler) to manage that module instead of LE's managing the > module > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Scott Ford IDMWORKS z/OS Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
>From the LE team: fetch() will indeed reject loading load module of another AMODE. This is related to the fact that LE will not only load the module into storage (with the LOAD macro) but will also manage some control blocks and data for the module, such as the load list table, the WSA and fetch-specific control blocks (FECB) etc, in order to make the module accessible to the current LE application. As someone suggested, you could add an assembler routine (or possibly inlined assembler) to manage that module instead of LE's managing the module Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
Why not just a general LINK31 routine to be called for any program … ACONTROL OPTABLE(ZS3) SPLEVEL SET=6Specify OS/390 R2 MACRO Format SYSSTATE ARCHLVL=2Program Requires Z/Architecture SYSSTATE OSREL=ZOSV1R13 Program Requires Z/OS 1.13 & Higher LINK31 CSECT , LINK31 AMODE 31 LINK31 RMODE ANY BAKR R14,0 LRR4,R0 Copy Parameter List Address LRR5,R1 Copy Program Name Address LARL R12,LINK31 Set Base Address USING LINK31,R12 SAM31 , STORAGE OBTAIN,LENGTH=WRKLEN,LOC=ANY LRR13,R1 USING WRKAREA,R13 LRR1,R4 Restore Parameter Address LINK EPLOC=(R5) Call Requested Program LRR4,R0 Copy Reason Code LRR5,R15 Copy Return Code STORAGE RELEASE,LENGTH=WRKLEN,ADDR=(R13) LRR0,R4 Restore Reason Code LRR15,R5 Restore Return Code PR, Return To Caller LTORG , WRKAREA DSECT , DS18F WRKLEN EQU *-WRKAREA YREGS , END , Then pass parms in R0 and the program name in R1. Could be used for IGGCSI00 or any other program when in 64 bit mode. Dan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
All this agita over invoking a straightforward system service routine like
IGGCSI00 argues strongly for an IBM-supplied and IBM supported "thunk" or
"glue" subroutine to enable such services to be used from AMODE64 programs.
Or even for an alternate AMODE64 environment from XPLINK, which frankly stinks
for applications written in any language except C/C++, and maybe even for C/C++
too. The restrictions and caveats of XPLINK are far too numerous to make it
even close to acceptable as a development-friendly environment.
There is no excuse for any standard AMODE31 service routine to be unavailable
from the AMODE64 environment. Something needs to exist and be supported by
IBM to dynamically call AMODE31 service routines easily and transparently (and
with minimal performance impact) from AMODE64 programs.
I for one don't expect IBM to create a unique version of IGGCSI00 callable from
AMODE64 programs, or for them to do that for any other existing AMODE31 service
routine. That effort, it seems to me, would be a waste of IBM's resources.
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Thursday, December 20, 2018 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64-bit C code fetching IGGCSI00
On Thu, 20 Dec 2018 10:17:12 -0500, Pierre Fichaud wrote:
>You can get around stack processing in 31-bit mode by using #pragma
>linkage(fred,OS) where fred is a non-LE module. I've done this often.
I haven't used #pragma linkage(fred,OS), but I have used extern "OS_NOSTACK"
{int fred(void);} in a 31-bit C program as well as in a 64-bit C program. I
assume you can use the #pragma as well.
But the fact remains that C must provide a save area to fred when it is called.
As far as I know, that save area comes from the stack, and for XPLINK-64, that
stack is above the bar.
Perhaps the reason fetch will not allow you to load an AMODE(31) program is to
prevent you from calling it, since an AMODE(31) program will fail as soon as it
used the low 31 bits of the save area address to save its caller's registers.
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
On Thu, 20 Dec 2018 10:17:12 -0500, Pierre Fichaud wrote:
>You can get around stack processing in 31-bit mode by using #pragma
>linkage(fred,OS) where fred is a non-LE module. I've done this often.
I haven't used #pragma linkage(fred,OS), but I have used
extern "OS_NOSTACK" {int fred(void);}
in a 31-bit C program as well as in a 64-bit C program. I assume you can use
the #pragma as well.
But the fact remains that C must provide a save area to fred when it is called.
As far as I know, that save area comes from the stack, and for XPLINK-64, that
stack is above the bar.
Perhaps the reason fetch will not allow you to load an AMODE(31) program is to
prevent you from calling it, since an AMODE(31) program will fail as soon as it
used the low 31 bits of the save area address to save its caller's registers.
--
Tom Marchant
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
Tom, If fetch is hard-wired to refuse a load of a 31-bit module while running in 64-bit mode, I need to write a 64-bit assembler front-end module. You can get around stack processing in 31-bit mode by using #pragma linkage(fred,OS) where fred is a non-LE module. I've done this often. But fetch() seems to be the show-stopper. Regards, Pierre On 2018-12-19 1:50 p.m., Tom Marchant wrote: 64-bit C is XPLINK. XPLINK-64 allocates the stack above the bar. The save area that is passed to a non-XPLINK program is allocated from the stack. Unless there is a way to alter this behavior, 64-bit C cannot call an AMODE(31) program. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
On Wed, 19 Dec 2018 09:28:53 -0500, Pierre Fichaud wrote: >I can't believe that an AMODE 31 module can't be fetched by 64-bit C >code. __malloc31() can be used to get 31-bit storage. Disclaimer: I am not a C guy. 64-bit C is XPLINK. XPLINK-64 allocates the stack above the bar. The save area that is passed to a non-XPLINK program is allocated from the stack. Unless there is a way to alter this behavior, 64-bit C cannot call an AMODE(31) program. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
I would expect the pragma to affect the call, not the fetch. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Wednesday, December 19, 2018 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64-bit C code fetching IGGCSI00 Hmm-m-m. Maybe #pragma linkage (IGGCSI00, OS_NOSTACK) would work? Also, investigate your C compile listing, what is the compiler option XPLINK set to? I get the impression from RTFM about the XPLINK option that XPLINK(OSCALL(NOSTACK)) is the default when LP64 is in effect, is that true for your compile? If so, maybe #pragma linkage(IGGCSI00,OS) would satisfy the runtime system? Just guessing here, haven't had time to cobble together a real example. As you said, hopefully someone from C/LE development can chime in and enlighten us all. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pierre Fichaud Sent: Wednesday, December 19, 2018 9:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64-bit C code fetching IGGCSI00 Peter, Using FETCHABLE gives me the same error. With OS_DOWNSTACK I get the followig when I build: CCN6404 (W) The parameter "OS_UPSTACK" specified for "pragma linkage" is not valid. The pragma is ignored. I ran it anyway and got the same thing. I can't believe that an AMODE 31 module can't be fetched by 64-bit C code. __malloc31() can be used to get 31-bit storage. Maybe someone from the C/LE IBM lab can add to this. Regards and thanks, Pierre. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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
Re: 64-bit C code fetching IGGCSI00
Hmm-m-m. Maybe #pragma linkage (IGGCSI00, OS_NOSTACK) would work? Also, investigate your C compile listing, what is the compiler option XPLINK set to? I get the impression from RTFM about the XPLINK option that XPLINK(OSCALL(NOSTACK)) is the default when LP64 is in effect, is that true for your compile? If so, maybe #pragma linkage(IGGCSI00,OS) would satisfy the runtime system? Just guessing here, haven't had time to cobble together a real example. As you said, hopefully someone from C/LE development can chime in and enlighten us all. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pierre Fichaud Sent: Wednesday, December 19, 2018 9:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 64-bit C code fetching IGGCSI00 Peter, Using FETCHABLE gives me the same error. With OS_DOWNSTACK I get the followig when I build: CCN6404 (W) The parameter "OS_UPSTACK" specified for "pragma linkage" is not valid. The pragma is ignored. I ran it anyway and got the same thing. I can't believe that an AMODE 31 module can't be fetched by 64-bit C code. __malloc31() can be used to get 31-bit storage. Maybe someone from the C/LE IBM lab can add to this. Regards and thanks, Pierre. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
Peter, Using FETCHABLE gives me the same error. With OS_DOWNSTACK I get the followig when I build: CCN6404 (W) The parameter "OS_UPSTACK" specified for "pragma linkage" is not valid. The pragma is ignored. I ran it anyway and got the same thing. I can't believe that an AMODE 31 module can't be fetched by 64-bit C code. __malloc31() can be used to get 31-bit storage. Maybe someone from the C/LE IBM lab can add to this. Regards and thanks, Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
So using these pragmas did not stop the fetch error? #pragma(IGGCSI00, FETCHABLE) #pragma(IGGCSI00, OS_UPSTACK) Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pierre Fichaud Sent: Tuesday, December 18, 2018 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 64-bit C code fetching IGGCSI00 I have 64-bit C code that attempts to fetch() IGGCSI00. I've used pragma linkage on IGGCSI00 but got nowhere. I am getting the following: EDC5256S An AMODE64 application is attempting to fetch() an AMODE31 executable. (errno2=0xC4070068) The C program was compiled with : langlvl(LIBEXT),ARCH(5),TUNE(7),GONUMBER,FLAG(I),XPLINK(STOREARGS),EXPORTALL,SPILL(448),LP64,GOFF Reading the doc on fetch() and XPLINK in the C/C++ and LE bookshleves doesn't shed nay light on this. I think I am forced to write a64-bit assembler program that then calls IGGCSI00 with parameters in 31-bit memory. Any suggestions ? Thanks in advance, Pierre. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
In article <8873109401385730.wa.m42tomibmmainyahoo@listserv.ua.edu> you wrote: > On Tue, 18 Dec 2018 12:24:38 -0600, Pierre Fichaud wrote: > >I have 64-bit C code that attempts to fetch() IGGCSI00. > >I've used pragma linkage on IGGCSI00 but got nowhere. > >I am getting the following: > > > >EDC5256S An AMODE64 application is attempting to fetch() an AMODE31 > >executable. (errno2=0xC4070068) > > > >The C program was compiled with : > >langlvl(LIBEXT),ARCH(5),TUNE(7),GONUMBER,FLAG(I),XPLINK(STOREARGS),EXPORTALL,SPILL(448),LP64,GOFF > > > >Reading the doc on fetch() and XPLINK in the C/C++ and LE bookshleves > >doesn't shed nay light on this. > >I think I am forced to write a64-bit assembler program that then calls > >IGGCSI00 with parameters in 31-bit memory. > I think you will need to write a small AMODE(64) assembler program that will > either LOAD, CALL, and DELETE IGGCSI00, or LINK to IGGCSI00. It isn't too > difficult. Some things to remember: > o The save area that XPLINK-64 provides will be above the bar. If that > behavior can be modified, I don't know how. > o Use F4SA format to save the registers on entry. LE will pass you a 144-byte > save area. > o GETMAIN storage for a 144-byte save area plus whatever other storage you > need for passing parameters. > o Save the 8-byte address of the save area you were passed in offset 128 > (X'80') of the new save area. > o Mark the new save area with "F4SA" in offset 4. > o Copy your parameters to your below the bar storage. > o SAM31 to go to AMODE(31) before making the call. > o If necessary, copy results to where your C program can find them. > o SAM64 before trying to restore registers. > -- > Tom Marchant The XPLINK asm macros will take care of all that stack bookkeeping. See doc on EDCXPRLG and EDCXEPLG. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
On Tue, 18 Dec 2018 12:24:38 -0600, Pierre Fichaud wrote: >I have 64-bit C code that attempts to fetch() IGGCSI00. >I've used pragma linkage on IGGCSI00 but got nowhere. >I am getting the following: > >EDC5256S An AMODE64 application is attempting to fetch() an AMODE31 >executable. (errno2=0xC4070068) > >The C program was compiled with : >langlvl(LIBEXT),ARCH(5),TUNE(7),GONUMBER,FLAG(I),XPLINK(STOREARGS),EXPORTALL,SPILL(448),LP64,GOFF > >Reading the doc on fetch() and XPLINK in the C/C++ and LE bookshleves doesn't >shed nay light on this. >I think I am forced to write a64-bit assembler program that then calls >IGGCSI00 with parameters in 31-bit memory. I think you will need to write a small AMODE(64) assembler program that will either LOAD, CALL, and DELETE IGGCSI00, or LINK to IGGCSI00. It isn't too difficult. Some things to remember: o The save area that XPLINK-64 provides will be above the bar. If that behavior can be modified, I don't know how. o Use F4SA format to save the registers on entry. LE will pass you a 144-byte save area. o GETMAIN storage for a 144-byte save area plus whatever other storage you need for passing parameters. o Save the 8-byte address of the save area you were passed in offset 128 (X'80') of the new save area. o Mark the new save area with "F4SA" in offset 4. o Copy your parameters to your below the bar storage. o SAM31 to go to AMODE(31) before making the call. o If necessary, copy results to where your C program can find them. o SAM64 before trying to restore registers. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
Don, I understand about the parameters and data areas being in 31-bit storage. I'm trying to fetch() IGGCSI00 in C code that is compiled for 64-bit. The fetch fails. Can I define IGGCSI00 somehow to C so that the fetch() works ? Regards, Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 64-bit C code fetching IGGCSI00
In article <5828839252973544.wa.prf51videotron...@listserv.ua.edu> you wrote: > I have 64-bit C code that attempts to fetch() IGGCSI00. > I've used pragma linkage on IGGCSI00 but got nowhere. > I am getting the following: > EDC5256S An AMODE64 application is attempting to fetch() an AMODE31 > executable. (errno2=0xC4070068) > The C program was compiled with : > langlvl(LIBEXT),ARCH(5),TUNE(7),GONUMBER,FLAG(I),XPLINK(STOREARGS),EXPORTALL,SPILL(448),LP64,GOFF > Reading the doc on fetch() and XPLINK in the C/C++ and LE bookshleves doesn't > shed nay light on this. > I think I am forced to write a64-bit assembler program that then calls > IGGCSI00 with parameters in 31-bit memory. > Any suggestions ? > Thanks in advance, Pierre. You can call any 31-bit assembler API from a 64-bit C program, but you have to jump through the hoops. Move all the parms (and anything the parms point to) below the bar and then SAM31/BASR/SAM64. If the API expects R13 to point to a save area, then you need to set that up too. You won't be using XPLINK parms, so setup the R1 parm area as well. Make sure to save and restore all the caller registers. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
64-bit C code fetching IGGCSI00
I have 64-bit C code that attempts to fetch() IGGCSI00. I've used pragma linkage on IGGCSI00 but got nowhere. I am getting the following: EDC5256S An AMODE64 application is attempting to fetch() an AMODE31 executable. (errno2=0xC4070068) The C program was compiled with : langlvl(LIBEXT),ARCH(5),TUNE(7),GONUMBER,FLAG(I),XPLINK(STOREARGS),EXPORTALL,SPILL(448),LP64,GOFF Reading the doc on fetch() and XPLINK in the C/C++ and LE bookshleves doesn't shed nay light on this. I think I am forced to write a64-bit assembler program that then calls IGGCSI00 with parameters in 31-bit memory. Any suggestions ? Thanks in advance, Pierre. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
