This portal is to open public enhancement requests against IBM Z Software products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Hi Colin,
To answer "please can you document how to call an program from 64 bit mode; and possibly 32 bit to 64 bit, 64 to 64, and 64 to 32 bit - bearing in mind addresses may be passed in a different mode to the execution mode."
- in terms of 64-bit XPLINK calls to 64-bit XPLINK, there is nothing special to consider
- in terms of 64-bit XPLINK calls to 64-bit OS linkage, one would need to use the #pragma linkage OS -- some details are at https://www.ibm.com/docs/en/zos/2.5.0?topic=descriptions-pragma-linkage-c-only
- in terms of mixed AMODE (ie. 32bit to 64bit, or 64bit to 32bit), only METAL C supports that -- see https://www.ibm.com/docs/en/zos/2.5.0?topic=c-amode-switching-support
- re: "bearing in mind addresses may be passed in a different mode to the execution mode." -- we support the __ptr32 and __ptr64 type qualifier -- see https://www.ibm.com/docs/en/zos/2.5.0?topic=qualifiers-ptr32-type-qualifier and https://www.ibm.com/docs/en/zos/2.5.0?topic=qualifiers-ptr64-type-qualifier-c-only
We also have some additional questions:
1. Does the caller run in amode 64?
2. Does the callee run in amode 64?
3. If not, what are they?
4. Do you have other types of caller to this code? like assembly caller and what is it's amode?
5. Regarding your comment of "This retuns in 24bit mode". We are not quite following where 24bit comes into play. Can you please elaborate?
6. Could we get a full (runnable) tc, with details explanation of the issue?
Thanks
Let me turn the problem around.
How should I invoke the program
CPWTO CSECT
CPWTO AMODE 64
CPWTO RMODE 64
BAKR R14,0
USING CPWTO,R14
LGR R3,R1
XGR R0,R0
LG R1,0(R1) first and only parm
* L R2,4(R1) A(h(len),data)
LR 14,1 FIRST BYTE OF PARM LIST
SR 15,15 CLEAR REGISTER 15
AH 15,0(1,0) ADD LENGTH OF TEXT + 4
AR 14,15 FIRST BYTE AFTER TEXT
SVC 35 Issue WTO
* SR 15,15
PR
This returns in 24 bit mode!
I need to have the extra BSM for it to work properly
If you do not give the option for BASR - please can you document how to call an program from 64 bit mode; and possibly 32 bit to 64 bit, 64 to 64, and 64 to 32 bit - bearing in mind addresses may be passed in a different mode to the execution mode.
This idea is being rejected for now.
Hi Colin, any updates regarding our Oct 3 post? Thanks.
Hi Colin,
We have been looking into the BALR instruction in detail. We have found docs mentioning that BALR is not really deprecated, but rather used for compatibility purposes. So the compiler generating BALR is not inaccurate.
However, we are trying to get a sense of why you need to do the extra BSM/BARK with BALR, but not with BASR? ie why is the BSM/BARK is needed, if you don't use the Program Return (PR) to return
Perhaps, it would be good to know what the assembly code is for "another version when not called by C", and how is that being called?
Looking forward to hearing back from you.
Hello Basil,
it is C on z/OS ( raising an RFE - for C did not give me a choice of z/OS or AIX...
I used
#pragma linkage(CPWTO , OS)
and the code produced was
* rc = CPWTO( "HI" );
LARL r8,F'1134'
LLGF r6,1208
LA r13,#NOSTACK_SA_1(,r4,2248)
LA r0,+CONSTANT_AREA(,r8,74)
LG r15,=V(CPWTO)(,r5,112)
LA r1,#MX_TEMP1(,r4,2176)
LG r6,#LCA_PTR(,r6,88)
STG r0,#MX_TEMP1(,r4,2176)
STG r4,#CAA_R4SA(,r6,32)
BALR r14,r15
NOPR 6
LGHI r0,H'0'
My request was that BALR is being used ( which is deprecated) instead of BASR.
My assembler code should not matter... ... but the code I had to write was
CPWTO CSECT
CPWTO AMODE 64
CPWTO RMODE 64
BSM 14,0
BAKR R14,0
USING CPWTO,R14
LGR R3,R1
XGR R0,R0
LG R1,0(R1) first and only parm
* L R2,4(R1) A(h(len),data)
LR 14,1 FIRST BYTE OF PARM LIST
SR 15,15 CLEAR REGISTER 15
AH 15,0(1,0) ADD LENGTH OF TEXT + 4
AR 14,15 FIRST BYTE AFTER TEXT
SVC 35 Issue WTO
* SR 15,15
PR
They were all 64 bit programs
Hi, we would like to confirm a few things regarding this Idea:
1) To confirm, is this Idea for C++ on AIX or z/OS?
2) If its for z/OS, can you please provide the exact AMODE/linkage (ie. pragma linkage) of the calling C program ?
3) Can you please also provide the exact AMODE/linkage of the "assembler program"?
4) Are you mixing AMODEs at all? between AMODE24, AMODE31, or AMODE64?
We look foreword to hearing back from you on the above questions.
Thanks for submitted this Idea. This Idea is being further investigated. We will update once a decision is made.