mp with a 64 bit address into my buffer in 31 bit address.
:>You have to use the correct ESSY block.
:>I could be deluded
It has been a while, but I already had am API for the 31 bit addresses and did
not want to change the API. The 64bit call will certainly do 31 bit zero
extended addres
..ABDPL+
>=A(ADPLSACC),..TYPE OF CALL: ACCESS STOR+
>MY_ADPLPACC),..ACCESS STORAGE PARM LIST +
>MF=(E,PLIST)
> L R15,ADPLSERV LOCATE IPCS SERVICE ROUTINE
> B
),..ACCESS STORAGE PARM LIST +
MF=(E,PLIST)
L R15,ADPLSERV LOCATE IPCS SERVICE ROUTINE
BASR R14,R15
The 64bit access call
has
> virtually nothing on how to access 64bit storage in an IPCS dump via a VERBX.
> I searched the internet and the only clue I found was a 7 year old post on
> this site by Don Poitras. He listed a routine in C that would access 64bit
> (and 31bit) storage. I have tried to mimic tha
, September 21, 2022 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IPCS VERBX 64bit storage
Hi all. I am new to this list but I have searched the archives for an answer
to my question already without any luck.
I am responsible for maintaining an IBM IPCS VERBX (verb exit) that analyzes
our
some of our data above the bar (ATB) and I need to update the
VERBX to analyze that data. Unfortunately the IBM doc has virtually nothing on
how to access 64bit storage in an IPCS dump via a VERBX. I searched the
internet and the only clue I found was a 7 year old post on this site by Don
01:33 -0400, Steve Thompson (ste...@copper.net)
> wrote about "Re: COBOL 64bit" (in
> ):
>
> [snip]
>> Assume that this data set is a VSAM KSDS. And assume that we do random
>> access of the records, and that those records contain pricing and rules
>>
f just doing random
> access on the file? Or am I misunderstanding?
>
> From: IBM Mainframe Discussion List on behalf of
> Steve Thompson
> Sent: Thursday, October 18, 2018 1:01 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: COBOL 64bit
On Thu, 18 Oct 2018 15:01:33 -0400, Steve Thompson (ste...@copper.net)
wrote about "Re: COBOL 64bit" (in
):
[snip]
> Assume that this data set is a VSAM KSDS. And assume that we do random
> access of the records, and that those records contain pricing and rules
> for same.
Wh
Subject: Re: COBOL 64bit
We have run into a situation, quite recently, where we would love
to have COBOL 6.2 to be doing 64bit storage because we need to
load a large table (actually, we want to load a data set into
storage).
Assume that this data set is a VSAM KSDS. And assume that we do
random access
+1
--
Peter Hunkeler
Von: "Farley, Peter x23353" An:
IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: COBOL 64bit Datum: 17.10.18, 23:29
The following is just my personal $0.02USD worth. I speak for myself only and
not for my employer.
Just like any other n
We have run into a situation, quite recently, where we would love
to have COBOL 6.2 to be doing 64bit storage because we need to
load a large table (actually, we want to load a data set into
storage).
Assume that this data set is a VSAM KSDS. And assume that we do
random access
Of Frank Swarbrick
Sent: Thursday, October 18, 2018 1:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 64bit
Related to this, we would require a 64-bit IMS DL/I interface and 64-bit CICS
LE application support before even considering a migration to 64-bit. Well, I
suppose we could leave
of our core data
is in IMS.
From: IBM Mainframe Discussion List on behalf of
Frank Swarbrick
Sent: Thursday, October 18, 2018 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 64bit
While I understand what you are saying, and mostly agree with it, I'm
sday, October 17, 2018 3:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 64bit
The following is just my personal $0.02USD worth. I speak for myself only and
not for my employer.
Just like any other new version of the COBOL compiler, 64-bit addressing
support must be able to be phase
No argument. The subject line was COBOL 64bit -- by implication AMODE 64 COBOL
-- and so that's where my reply was coming from.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Thursday, October 18, 2018 7
On Wed, 17 Oct 2018 15:20:44 -0700, Charles Mills wrote:
>And FWIW there is another overlapping complexity here besides AMODE 64
>-- speaking in theory only, because there is no reality of 64-bit COBOL.
It isn't really "theory only" because it is true of assembler too.
>There are really
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, October 18, 2018 4:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 64bit
Don't expect anyone else to save it, so if you really need it after you
Don't expect anyone else to save it, so if you really need it after you
get started then save again in your own storage before you call someone
else who may or may not preserve it.
I disagree. That's what linkage conventions are for. Sure, if a callee
fails to follow them (and fails to
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Farley, Peter x23353
Sent: Wednesday, October 17, 2018 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 64bit
The simple answer to the "problem child" case is not &qu
ou call someone else who may or may not preserve it.
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, October 17, 2018 6:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 64bit
On Wed, 17 Oct
On Wed, 17 Oct 2018 15:20:44 -0700, Charles Mills wrote:
>And FWIW there is another overlapping complexity here besides AMODE 64 --
>speaking in theory only, because there is no reality of 64-bit COBOL.
>
>... A program could be AMODE 31 but either destroy the high halves of a
>caller's
o:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Wednesday, October 17, 2018 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL 64bit
On Wed, 17 Oct 2018 15:37:12 -0500, Allan Kielstra wrote:
>It is only available in 31-bit.
>
>An interesting question to ask is: if it were
On Wed, 17 Oct 2018 15:37:12 -0500, Allan Kielstra wrote:
>It is only available in 31-bit.
>
>An interesting question to ask is: if it were available in 64-bit but mixing
>and matching 31- and 64-bit modules was not possible (i.e., you would have to
>recompile all modules in an application),
V.UA.EDU
Subject: Re: COBOL 64bit
EXTERNAL EMAIL
It is only available in 31-bit.
An interesting question to ask is: if it were available in 64-bit but mixing
and matching 31- and 64-bit modules was not possible (i.e., you would have to
recompile all modules in an application), would
It is only available in 31-bit.
An interesting question to ask is: if it were available in 64-bit but mixing
and matching 31- and 64-bit modules was not possible (i.e., you would have to
recompile all modules in an application), would that be interesting? Or is it
the case that it is vital
Just an easy question - does anyone know if COBOL can be 64 bit or is it still
only 31 bit?
Lizette
Sent from EarthLink Mobile mail
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
In
caarmm9rskjgk-ypgufnhowtvkpbjbykdk0cr2i3vnnrrurx...@mail.gmail.com,
on 10/21/2014
at 11:59 AM, Tony Harminc t...@harminc.net said:
Here's the epilog code for a non-main function generated by an oldish
version of IBM C:
Doesn't the use of R1 violate the czlling convention?
00011A 051E
On 22 October 2014 18:34, Shmuel Metz (Seymour J.)
shmuel+ibm-m...@patriot.net wrote:
Here's the epilog code for a non-main function generated by an oldish
version of IBM C:
Doesn't the use of R1 violate the czlling convention?
It's an internal czll/rdturn, so they can do what they like.
Tony
Tony H wrote
| It's an internal czll/rdturn, so they can
| do what they like.
Not quite. There was[is?] an internal-to-IBM scheme for requesting
[and receiving] exceptions from programming standards which IBM PL/I
development groups used fairly often. A cogent, chiefly technical
case had to be
We do this always in our site-specific startup and return macros
for ASSEMBLER programs; this way in save area trace, the program
levels already returned show up by odd return addresses. It can be of
some help in strange situations, where save area chains are partially
destroyed.
Kind regards
Am 21.10.2014 19:53, schrieb Don Poitras:
In article caarmm9rskjgk-ypgufnhowtvkpbjbykdk0cr2i3vnnrrurx...@mail.gmail.com
you wrote:
On 21 October 2014 10:09, Tom Marchant
000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote:
I've never seen a case where BALR is used to return to the caller.
There are several areas where LE does not agree well with the
calling conventions, as I learned them in the mid 80s.
- forward save area chaining (never done by LE, turning SYSUDUMP
save area traces useless ... we fix this in our site specific interface
modules,
which are used between every two
An AMODE 64 target routine often needs to edict whether it is to be
entered by BASSM vs BASR/BALR (it cannot force that to be done, but it
may misbehave if the edict is not followed). A fairly typical convention
is for the target routine to capture the caller's AMODE in R14 via BSM
14,0 so
On Wed, Oct 22, 2014 at 6:46 AM, Peter Relson rel...@us.ibm.com wrote:
An AMODE 64 target routine often needs to edict whether it is to be
entered by BASSM vs BASR/BALR (it cannot force that to be done, but it
may misbehave if the edict is not followed).
I guess that using the return
On Fri, 17 Oct 2014 16:36:38 -0400, Don Poitras wrote:
I guess it depends what you mean by I would like to use 64bit storage
for some functions from Cobol. If the Cobol part is never going to
directly use the memory, then there's no problem in a called program
in another language using above
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Tom Marchant
On Fri, 17 Oct 2014 16:36:38 -0400, Don Poitras wrote:
I guess it depends what you mean by I would like to use 64bit storage
for some functions from Cobol. If the Cobol part is never going
On Tue, 21 Oct 2014 07:30:32 -0500, Tom Marchant wrote:
If you have an assembler called program, you don't need to issue SAM31 before
returning as long as you were called with one of BASSM, BASR or BALR. In all
of
these cases the return register (R14) contains sufficient information so that
Chase, John wrote:
But see APAR PI17184 for an instance when BSM did not return correctly.
Curious PER, hmmm. Is that only for COBOL 5.1 programs running under CICS?
With what LE version is that APAR?
Groete / Greetings
Elardus Engelbrecht
On Tue, 21 Oct 2014 13:31:44 +, Chase, John wrote:
From: IBM Mainframe Discussion List On Behalf Of Tom Marchant
If you have an assembler called program, you don't need to issue SAM31
before returning as long as you
were called with one of BASSM, BASR or BALR. In all of these cases
On Tue, 21 Oct 2014 08:49:26 -0500, Paul Gilmartin wrote:
On Tue, 21 Oct 2014 07:30:32 -0500, Tom Marchant wrote:
If you have an assembler called program, you don't need to issue SAM31 before
returning as long as you were called with one of BASSM, BASR or BALR. In all
of
these cases the
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht
Chase, John wrote:
But see APAR PI17184 for an instance when BSM did not return correctly.
Curious PER, hmmm. Is that only for COBOL 5.1 programs running under CICS?
That was the situation
On Tue, 21 Oct 2014 09:18:52 -0500, Tom Marchant wrote:
I stand corrected. BALR and BASR do not set bit 63 of the return register if
in
AMODE 64, so what I wrote earlier applies only to AMODE 24 or 31 callers using
those instructions. BASSM always provides the correct information for BSM to
Chase, John wrote:
Curious PER, hmmm. Is that only for COBOL 5.1 programs running under CICS?
That was the situation when I opened the PMR for which the APAR was opened.
Presumably it could have occurred in a batch program as well.
Ok.
With what LE version is that APAR?
z/OS 1.13
Tom Marchant wrote:
begin extract
So, yes, if your program changes the AMODE after receiving control, you should
change it back to what it was. And not just blindly set it to AMODE 31.
/end extract
and this is supremely good generic advice. I am hard put even to
fantasticate a situation in
On Tue, 21 Oct 2014 09:29:56 -0500, Paul Gilmartin wrote:
I see in SYS1.MACLIB(RETURN):
OI15(13),X'01' SET RETURN INDICATION
0160
Yes, It is done after the registers are restored, and it is only if T is
specified
after the registers to be restored.
On 21 October 2014 10:09, Tom Marchant
000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote:
I've never seen a case where BALR is used to return to the caller.
Well... Here's the epilog code for a non-main function generated by an
oldish version of IBM C:
00010EStart of
In article caarmm9rskjgk-ypgufnhowtvkpbjbykdk0cr2i3vnnrrurx...@mail.gmail.com
you wrote:
On 21 October 2014 10:09, Tom Marchant
000a2a8c2020-dmarc-requ...@listserv.ua.edu wrote:
I've never seen a case where BALR is used to return to the caller.
Well... Here's the epilog code for a
. We call hlasm
subroutines. I would like to use 64bit storage for some functions from
Cobol. Is this feasible. I think it is, where I am unclear is the call and
binder parameters. Do I have to do anything special parameter wise
Tom,
No problem..I want to head our products toward 64bit ..So changing our existing
COBOL code was my first choice.
But it looks like I will head us for C or C++ with Assembler called routines.
But I appreciate the email for sure.
Regards,
Scott
www.identityforge
From: Tom Ross
Sent
As I read thru the MVS Extended Addressability Guide
I am trying to understand restrictions,
In general, you should assume that a z/OS service does not support AMODE
64 unless it says it does.
In general, you should assume that a z/OS service that supports AMODE 64
does not support data above
On Sat, 18 Oct 2014 10:11:15 -0400, Peter Relson wrote:
In general, you should assume that a z/OS service that supports AMODE 64
does not support data above 2G unless it says it does.
If it does not, there's not a whole lot of rationale for (claiming to)
support AMODE 64.
-- gil
Subject: Re: 64bit
On Sat, 18 Oct 2014 10:11:15 -0400, Peter Relson wrote:
In general, you should assume that a z/OS service that supports AMODE
64 does not support data above 2G unless it says it does.
If it does not, there's not a whole lot of rationale for (claiming to) support
AMODE 64
Never mind. Should not post before coffee.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Charles Mills
Sent: Saturday, October 18, 2014 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64bit
It means junk that happens
Paul,
There would certainly be no rationale for having AMODE(64) if there
were no above-the-bar virtual storage. Since, however, we do have
this storage there is sometimes a rationale for using AMODE(64) below
the bar, and the ability to invoke a facility from AMODE(64) code is
then also
get to the future is the latest, most recent, current instance of the
present. Ergo, CoBOL is not for us.
'Nuff said!
;-)
===
Date: Thu, 16 Oct 2014 10:17:56 -0400
From: 0006f84450fa-dmarc-requ...@listserv.ua.edu
Subject: 64bit
To: IBM-MAIN@LISTSERV.UA.EDU
All,
I have
On Sat, 18 Oct 2014 11:16:13 -0400, John Gilmore wrote:
There would certainly be no rationale for having AMODE(64) if there
were no above-the-bar virtual storage. Since, however, we do have
this storage there is sometimes a rationale for using AMODE(64) below
the bar, and the ability to invoke a
Perhaps I misunderstood the problem.
Whether called by the system, Cobol, or anything else, an HLASM routine
can get any storage that its authorization allows it to. That includes
storage below the bar, above the bar, and in data spaces. The routine can
switch in and out of any AMODE that its
I was interpreting Scott's question as how can above-the-bar memory be used
directly by COBOL.
On Fri, Oct 17, 2014 at 5:06 AM, Peter Relson rel...@us.ibm.com wrote:
Perhaps I misunderstood the problem.
Whether called by the system, Cobol, or anything else, an HLASM routine
can get any
In article CAFMxNWL0GLo1kCpEMokfozjhqVBN8VyUHUON4eWxC=c5Y=8...@mail.gmail.com
you wrote:
I was interpreting Scott's question as how can above-the-bar memory be used
directly by COBOL.
Which is why Peter was confused. No such support currently exists. While
there's been a lot of talk about
All,
C and C++ I know supports it , If my old eyes read correctly. Hlasm does. If I
am just using 64bit storage to store/retrieve data that should work?
Scott ford
www.identityforge.com
from my IPAD
On Oct 17, 2014, at 2:11 PM, Don Poitras poit...@pobox.com wrote:
In article
I guess it depends what you mean by I would like to use 64bit storage
for some functions from Cobol. If the Cobol part is never going to
directly use the memory, then there's no problem in a called program
in another language using above the bar storage. Just remember to
SAM 31 before you return
Ford
Sent: Friday, October 17, 2014 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64bit
All,
C and C++ I know supports it , If my old eyes read correctly. Hlasm does. If
I am just using 64bit storage to store/retrieve data that should work?
Scott ford
www.identityforge.com
from my IPAD
@LISTSERV.UA.EDU
Subject: Re: 64bit
All,
C and C++ I know supports it , If my old eyes read correctly. Hlasm does. If
I am just using 64bit storage to store/retrieve data that should work?
Scott ford
www.identityforge.com
from my IPAD
On Oct 17, 2014, at 2:11 PM, Don Poitras poit
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Scott Ford
Sent: Friday, October 17, 2014 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64bit
Charles,
The more I see the more I want/will convert the Cobol code to C or C
Charles:
I couldn't have said it any better. I also want to use 64bit as I eluded to in
my previous note.
As I read thru the MVS Extended Addressability Guide I am trying to understand
restrictions, especially when you in a
mixed Language environment. I have done a lot of looking
, tampering, amendment or viruses or any consequence thereof.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Friday, October 17, 2014 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64bit
These remarks
other assembler program.)
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Scott Ford
Sent: Friday, October 17, 2014 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64bit
All,
C and C++ I know supports it , If my
definition.
The only issue I run into with 64bit C/C++ code is having to deal with
assembler service routines that were written for 32bit. And you can't
just recompile
with a different compiler option to make them 64bit!
--
For IBM
You're right. uchar but no uint. You got my drift.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Friday, October 17, 2014 7:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64bit
On 18/10/2014 5:19 AM
All,
I have a generalized design question. First background will help. Our products
run as Enterprise Cobol STC, no multi-tasking, yet. We call hlasm subroutines.
I would like to use 64bit storage for some functions from Cobol. Is this
feasible. I think it is, where I am unclear is the call
, no multi-tasking, yet. We call hlasm
subroutines. I would like to use 64bit storage for some functions from
Cobol. Is this feasible. I think it is, where I am unclear is the call and
binder parameters. Do I have to do anything special parameter wise ?
Thanks as always,
Regards,
Scott ford
72 matches
Mail list logo
