BALR 14,15 invoke overflow routine
> * at this point R0 has the new NAB, R2 has the newly acquired address
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent
* at this point R0 has the new NAB, R2 has the newly acquired address
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John McKown
Sent: Tuesday, February 6, 2018 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RDJFCB fu
On Tue, Feb 6, 2018 at 2:38 PM, Charles Mills wrote:
> I found my approach below in the IBM documentation on my "day one" of
> C++/assembler integration. I have never done it any other way.
>
> What you are doing is appealing. There is something annoyingly inefficient
> about a 32-bit pointer to
6, 2018 11:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RDJFCB function in C++
On Tue, Feb 6, 2018 at 1:26 PM, Charles Mills wrote:
> e.g.
>
> #ifdef __MVS__
> extern "OS" {
> #endif
> void ABEND(const int code, const int reason);
> int GETJESND(char JES_node[9])
On Tue, Feb 6, 2018 at 1:26 PM, Charles Mills wrote:
> e.g.
>
> #ifdef __MVS__
> extern "OS" {
> #endif
> void ABEND(const int code, const int reason);
> int GETJESND(char JES_node[9]);
> #ifdef __MVS__
> }
> #endif
>
> Charles
>
Thanks! I now see where you're coming from by using the e
ohn McKown
Sent: Tuesday, February 6, 2018 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RDJFCB function in C++
On Tue, Feb 6, 2018 at 12:30 PM, Charles Mills wrote:
> +2
>
> Full C/C++ does require LE or XPLINK linkage, but there is a macro and
> it is not difficult at all. And
On Tue, Feb 6, 2018 at 12:30 PM, Charles Mills wrote:
> +2
>
> Full C/C++ does require LE or XPLINK linkage, but there is a macro and it
> is not difficult at all. And once you have done one, the next one is
> trivial. And you have to remember how C linkage works in general. If you
> call some as
Subject: Re: RDJFCB function in C++
+1
C's support for imbedded assembler is sometimes useful for a very few
instructions. I've attempted ATTACH in imbedded asm code, and the result was
hideodious (and I found a bug anyway). The linkage for Metal C is quite
standard and easy to use, pl
+1
C's support for imbedded assembler is sometimes useful for a very few
instructions. I've attempted ATTACH in imbedded asm code, and the result
was hideodious (and I found a bug anyway). The linkage for Metal C is
quite standard and easy to use, plus you get stack space, so there's
usually no
On Mon, Feb 5, 2018 at 3:28 PM, Seymour J Metz wrote:
> Actually, IBM recommends use of RDJFCB rather than direct use of SWAREQ,
> or at least used to. Note that with RDJFCB you can request an ARL for a
> concatenation rather than just the information for a single DD. However,
> it is certainly
>IIRC RDJFCB will give you space requested, but not space used.
Right. We once had the same issue and decided to use an ISPF service to get
that information. A little drawback: The program had to be run under batch TSO.
This was fine for us, but YMMV.
I can dig out that code if you're interes
frame Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, February 5, 2018 1:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RDJFCB function in C++
You can't get all of that with RDJFCB; you also need OBTAIN. If you really
need the space used, the
metz3
From: IBM Mainframe Discussion List on behalf of
Patrick Roehl
Sent: Monday, February 5, 2018 11:29 AM
To: IBM-MAIN@listserv.ua.edu
Subject: RDJFCB function in C++
I'm writing some new code in C++ and can't find how to get info normally found
in RDJFCB. Specifically, I'm
-MAIN@listserv.ua.edu
Subject: Re: RDJFCB function in C++
IIRC, I had a similar problem once, when trying to retrieve
the DS name from a 3 byte item which was located in the TIOT
near the DD name. This was not possible to do using pure C, because
the 3 byte item (which was an address in early stages o
Gilbert Saint-Flour is credited for this in the CBT file 183. It fails
however at z/OS 2.2 and later. I submitted a fixed version you can find
on the current tape.
http://www.cbttape.org/
In article <680af6cc-ea22-b251-4667-f55936f3e...@gmail.com> you wrote:
> The following snippet of REXX came f
On 2018-02-05 17:23, Bernd Oppolzer wrote:
IIRC, I had a similar problem once, when trying to retrieve
the DS name from a 3 byte item which was located in the TIOT
near the DD name. This was not possible to do using pure C, because
the 3 byte item (which was an address in early stages of MVS) now
On Mon, Feb 5, 2018 at 10:29 AM, Patrick Roehl
wrote:
> I'm writing some new code in C++ and can't find how to get info normally
> found in RDJFCB. Specifically, I'm looking for getting info on an existing
> dataset: space used, unit & volser, disposition, etc.
>
>
Which version of z/OS? I ask
IIRC, I had a similar problem once, when trying to retrieve
the DS name from a 3 byte item which was located in the TIOT
near the DD name. This was not possible to do using pure C, because
the 3 byte item (which was an address in early stages of MVS) now
is a sort of handle to an area which has mo
information you want may be available
from fldata().
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Patrick Roehl
Sent: Monday, February 5, 2018 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RDJFCB function in C++
I'm wr
I'm writing some new code in C++ and can't find how to get info normally found
in RDJFCB. Specifically, I'm looking for getting info on an existing dataset:
space used, unit & volser, disposition, etc.
--
For IBM-MAIN subscribe
20 matches
Mail list logo
