Re: RDJFCB function in C++

[Kirk Wolf]

We use XPLINK for our C++ code, and our assembler routines generally use
EDCXPRLG/EDCXEPLG.
There are a bunch of options on these macros that allow you to customize
the kind of XPLINK entry/exit code that you need.

Our prototypes use "C" linkage (which is slightly different and a little
better IMO than "OS_DOWNSTACK".
The thing to do is to take a look at various linkage options and see what
assembler gets generated by the compiler - makes everything clear.

One very nice thing to do is to use the XPLINK stack in your assembler
routine for working storage, save areas. etc.
The CEEDSA macro is essential for using the stack.



Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Feb 6, 2018 at 3:17 PM, Charles Mills <charl...@mcn.org> wrote:

> > since they seem to use J
>
> Nyah. Too advanced. Given SYSSTATE ARCHLVL=2,OSREL=ZOSV1R6 I see
>
>  USING *,15
> ABENDB IHB0002B   branch around prologue's constant areas
> * PPA1 constant area
>  DCAL1(IHB0002N+4-*)   offset to the name
>  DCX'CE' . CEE signature
>  DCX'A0' . CEE flags (ext proc, has DSA)
>  DCAL1(0+0+16)  .  member flags
>
> And
>
>  CL0,12(,12)   check for stack overflow
>  BNH   *+10branch if enough space
>  L 15,116(,12) load overflow rtn entry address
>  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: Tuesday, February 6, 2018 12:53 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RDJFCB function in C++
>
> On Tue, Feb 6, 2018 at 2:38 PM, Charles Mills <charl...@mcn.org> 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 a 32-bit copy of a 32-bit value.
> > I don't think I ever pass shorts but I guess that would lead to a
> > 32-bit pointer to a 32-bit copy of a 16-bit value, given C's integer
> > promotion. (XPLINK is better IIRC.)
> >
> > Do you use EDCPRLG and EDCEPIL with your approach?
> >
>
> ​Nope - I use the "standard" LE macros: CEEENTRY MAIN=NO and CEETERM.​ I
> guess that I should use the EDC* macros since they seem to use J...
> instructions instead of B...
>
> --
> 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: RDJFCB function in C++

[Charles Mills]

> since they seem to use J

Nyah. Too advanced. Given SYSSTATE ARCHLVL=2,OSREL=ZOSV1R6 I see

 USING *,15  
ABENDB IHB0002B   branch around prologue's constant areas
* PPA1 constant area 
 DCAL1(IHB0002N+4-*)   offset to the name
 DCX'CE' . CEE signature 
 DCX'A0' . CEE flags (ext proc, has DSA) 
 DCAL1(0+0+16)  .  member flags  

And 

 CL0,12(,12)   check for stack overflow  
 BNH   *+10branch if enough space
 L 15,116(,12) load overflow rtn entry address   
 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: Tuesday, February 6, 2018 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RDJFCB function in C++

On Tue, Feb 6, 2018 at 2:38 PM, Charles Mills <charl...@mcn.org> 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 a 32-bit copy of a 32-bit value. 
> I don't think I ever pass shorts but I guess that would lead to a 
> 32-bit pointer to a 32-bit copy of a 16-bit value, given C's integer 
> promotion. (XPLINK is better IIRC.)
>
> Do you use EDCPRLG and EDCEPIL with your approach?
>

​Nope - I use the "standard" LE macros: CEEENTRY MAIN=NO and CEETERM.​ I guess 
that I should use the EDC* macros since they seem to use J...
instructions instead of B...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[John McKown]

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 a 32-bit copy of a 32-bit value. I don't think I
> ever pass shorts but I guess that would lead to a 32-bit pointer to a
> 32-bit copy of a 16-bit value, given C's integer promotion. (XPLINK is
> better IIRC.)
>
> Do you use EDCPRLG and EDCEPIL with your approach?
>

​Nope - I use the "standard" LE macros: CEEENTRY MAIN=NO and CEETERM.​ I
guess that I should use the EDC* macros since they seem to use J...
instructions instead of B...



>
> BTW, with the "OS" linkage, 32-bit return values come back as you would
> expect in R15. 64-bit return values come back rather astonishingly in the
> low-order 32 bits of R15 (high word) and R0 (low word).
>
> Charles
>
>

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[Charles Mills]

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 a 32-bit copy of a 32-bit value. I don't think I ever 
pass shorts but I guess that would lead to a 32-bit pointer to a 32-bit copy of 
a 16-bit value, given C's integer promotion. (XPLINK is better IIRC.)

Do you use EDCPRLG and EDCEPIL with your approach?

BTW, with the "OS" linkage, 32-bit return values come back as you would expect 
in R15. 64-bit return values come back rather astonishingly in the low-order 32 
bits of R15 (high word) and R0 (low word).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, February 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 <charl...@mcn.org> 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 extern "OS" {...}.
I will go into an internal three way argument over which is better to do:
(1) Use the extern "OS" facility to use a historic OS calling sequence or
(2) structure my HLASM code to have a C calling sequence. Most likely I'll 
decide "it depends" on what I think the usage will be.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[John McKown]

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 extern "OS" {...}.
I will go into an internal three way argument over which is better to do:
(1) Use the extern "OS" facility to use a historic OS calling sequence or
(2) structure my HLASM code to have a C calling sequence. Most likely I'll
decide "it depends" on what I think the usage will be.


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[Charles Mills]

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John 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 <charl...@mcn.org> 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 assembler declared as
>
> void FOO(int x, char y[])
>
> the assembler code gets R1 pointing to (+0) the address of a temporary 
> copy of x and (+4) the address of y.
>

​How is FOO prototyped? In my LE enabled HLASM subroutines which are called 
from C, I don't do anything "fancy" in the prototype. E.g. If I have a function 
which returns an "int" and takes an "int" and a char *, I prototype it as:

int asmfunc(int x, char *y);

In this case, the return value (int) is returned in GPR15. GPR1 points to two 
fullwords. The first fullword contains the _value_ of ​x. The second fullword 
contains a pointer to y[0].

I know that there are "pragmas" which can change this so that "asmfunc" is 
called using standard OS linkage. But I simply don't use them. And, no, I don't 
know why I don't.



>
> Charles
>
>
--
I have a theory that it's impossible to prove anything, but I can't prove it.

Maranatha! <><
John McKown

--
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: RDJFCB function in C++

[John McKown]

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 assembler declared as
>
> void FOO(int x, char y[])
>
> the assembler code gets R1 pointing to (+0) the address of a temporary
> copy of x and (+4) the address of y.
>

​How is FOO prototyped? In my LE enabled HLASM subroutines which are called
from C, I don't do anything "fancy" in the prototype. E.g. If I have a
function which returns an "int" and takes an "int" and a char *, I
prototype it as:

int asmfunc(int x, char *y);

In this case, the return value (int) is returned in GPR15. GPR1 points to
two fullwords. The first fullword contains the _value_ of ​x. The second
fullword contains a pointer to y[0].

I know that there are "pragmas" which can change this so that "asmfunc" is
called using standard OS linkage. But I simply don't use them. And, no, I
don't know why I don't.



>
> Charles
>
>
-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[Charles Mills]

+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 assembler 
declared as

void FOO(int x, char y[])

the assembler code gets R1 pointing to (+0) the address of a temporary copy of 
x and (+4) the address of y.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Tuesday, February 6, 2018 9:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
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, plus you get stack space, so there's usually no need 
for GETMAIN. "Full" C may require LE conventions, although there may be options.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[Steve Smith]

+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 need for GETMAIN. "Full" C may require LE conventions, although
there may be options.

sas

On Tue, Feb 6, 2018 at 11:47 AM, Kirk Wolf  wrote:

> 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 possible to retrieve the information using pure C,
> although
> > the code wouldn't be as clean and might stop working in a future release.
> >
> >
> Exactly.  It is much better IMO to write small Assembler routines for these
> kind of things and then call them from C/C++/whatever
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[Kirk Wolf]

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 possible to retrieve the information using pure C, although
> the code wouldn't be as clean and might stop working in a future release.
>
>
Exactly.  It is much better IMO to write small Assembler routines for these
kind of things and then call them from C/C++/whatever

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: RDJFCB function in C++

[Peter Hunkeler]

>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 interested.

--Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[Charles Mills]

IIRC RDJFCB will give you space requested, but not space used. IOW, for
DISP=NEW,SPACE=xxx it will give you that xxx; but for DISP=OLD SPACE omitted
it will give you only the implicit information that SPACE was omitted, not
the size of the old dataset.

It's the same for many of the DD parameters, right? If the JCL says RECFM=F
it will give you that, but if it is DISP=OLD/SHR/MOD and RECFM is not coded,
it will not tell you the existing RECFM. Ditto BLKSIZE, etc.

The JFCB is more or less the DD statement in binary form, nothing more.

Charles


-Original Message-
From: IBM Mainframe 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, then write an assembler routine to do an RDJFCB with an
ARL and to do an OBTAIN for each dataset.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[Seymour J Metz]

You can't get all of that with RDJFCB; you also need OBTAIN. If you really need 
the space used, then write an assembler routine to do an RDJFCB with an ARL and 
to do an OBTAIN for each dataset.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


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 looking for getting info on an existing dataset: 
space used, unit & volser, disposition, etc.

--
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: RDJFCB function in C++

[Seymour J Metz]

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 
possible to retrieve the information using pure C, although the code wouldn't 
be as clean and might stop working in a future release.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Bernd Oppolzer <bernd.oppol...@t-online.de>
Sent: Monday, February 5, 2018 12:24 PM
To: IBM-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 of MVS) now
is a sort of handle to an area which has moved above the line,
and to translate this handle to an address, you need the SWAREQ macro.

I ended up writing a wrapper for SWAREQ, usable from C, in ASSEMBLER.

Look here:


CSWAREQ  CSECT
*
*---
*
*int cswareq (char *psva, char **ppjfcb);
*
*PSVA IST DER ZEIGER AUF EIN SVA-HANDLE
*(Z.B. DER JFBC-POINTER AUS DER TIOT).
*
*ZU DIESEM SVA-HANDLE LIEFERT SWAREQ
*DIE ECHTE ADRESSE (DER JFCB LIEGT IN DER SWA -
*SCHEDULER WORK AREA -, DESHALB IST DAS ETWAS
*KOMPLIZIERTER).
*
*DIE ADRESSE DES JFCB WIRD IM ERFOLGSFALL AN
*DEN AUFRUFER ALS 2. PARAMETER ZURUECKGEGEBEN.
*
*---
*
  STM   14,12,12(13)
  LR11,15
  USING CSWAREQ,11
  LA15,SAVEAREA
  ST15,8(13)
  ST13,4(15)
  LR13,15
*
  L 4,0(1)  ADRESSE SVA
  L 5,4(1)  ADRESSE DES JFCB-POINTERS
*
  LA6,EPA   ADRESSE EPA NACH AEPA
  ST6,AEPA
  USING ZB505,6
  XCSWAEPAX,SWAEPAX EPA INITIALISIEREN
*
  MVC   SWVA,0(4)
  SWAREQ FCODE=RL,EPA=AEPA,UNAUTH=YES,MF=(E,SWAPARMS)
*
  LTR   15,15
  BZRETOK
*
  XC0(4,5),0(5)
  B RET
*
RETOKDS0H
  MVC   0(4,5),SWBLKPTR
*
RET  DS0H
  L 13,4(13)
  L 14,12(13)
  LM0,12,20(13)
  BR14
*
*---
*
SAVEAREA DS18F
*
AEPA DSA
EPA  DSCL28
*
SWAPARMS SWAREQ MF=L
*
  CVT   DSECT=YES
*
  IEFJESCT
*
  IEFZB505 LOCEPAX=YES
*
  END

HTH, kind regards

Bernd



Am 05.02.2018 um 17:29 schrieb Patrick Roehl:
> 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 / 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[Don Poitras]

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 from an exec by Frank Clarke, it should be 
> fairly easy to translate it to C(++):
> ptr: return c2d(storage(d2x(arg(1)), 4))
> stg: return storage(d2x(arg(1)), arg(2))
> swareq: procedure
>   if right(c2x(arg(1)), 1) \= 'F' then/* SWA=BELOW ?  */
> return c2d(arg(1)) + 16   /* yes, return sva + 16 */
>   sva  = c2d(arg(1))  /* convert to decimal   */
>   tcb  = c2d(storage(21c, 4)) /* TCB PSATOLD  */
>   tcb  = ptr(540) /* TCB PSATOLD  */
>   jscb = ptr(tcb + 180)   /* JSCB TCBJSCB */
>   qmpl = ptr(jscb + 244)  /* QMPL JSCBQMPI*/
>   qmat = ptr(qmpl + 24)   /* QMAT QMADD   */
>   do while sva > 65536
> qmat = ptr(qmat + 12) /* next QMAT QMAT + 12  */
> sva  = sva - 65536/* 010006F -> 06F   */
>   end
> return ptr(qmat + sva + 1) + 16
> -- 
> Robert AH Prins
> robert.ah.prins(a)gmail.com

-- 
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: RDJFCB function in C++

[Robert Prins]

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
is a sort of handle to an area which has moved above the line,
and to translate this handle to an address, you need the SWAREQ macro.

I ended up writing a wrapper for SWAREQ, usable from C, in ASSEMBLER.

Look here:


CSWAREQ  CSECT
*
*---
*
*    int cswareq (char *psva, char **ppjfcb);
*
*    PSVA IST DER ZEIGER AUF EIN SVA-HANDLE
*    (Z.B. DER JFBC-POINTER AUS DER TIOT).
*
*    ZU DIESEM SVA-HANDLE LIEFERT SWAREQ
*    DIE ECHTE ADRESSE (DER JFCB LIEGT IN DER SWA -
*    SCHEDULER WORK AREA -, DESHALB IST DAS ETWAS
*    KOMPLIZIERTER).
*
*    DIE ADRESSE DES JFCB WIRD IM ERFOLGSFALL AN
*    DEN AUFRUFER ALS 2. PARAMETER ZURUECKGEGEBEN.
*
*---
*
  STM   14,12,12(13)
  LR    11,15
  USING CSWAREQ,11
  LA    15,SAVEAREA
  ST    15,8(13)
  ST    13,4(15)
  LR    13,15
*
  L 4,0(1)  ADRESSE SVA
  L 5,4(1)  ADRESSE DES JFCB-POINTERS
*
  LA    6,EPA   ADRESSE EPA NACH AEPA
  ST    6,AEPA
  USING ZB505,6
  XC    SWAEPAX,SWAEPAX EPA INITIALISIEREN
*
  MVC   SWVA,0(4)
  SWAREQ FCODE=RL,EPA=AEPA,UNAUTH=YES,MF=(E,SWAPARMS)
*
  LTR   15,15
  BZ    RETOK
*
  XC    0(4,5),0(5)
  B RET
*
RETOK    DS    0H
  MVC   0(4,5),SWBLKPTR
*
RET  DS    0H
  L 13,4(13)
  L 14,12(13)
  LM    0,12,20(13)
  BR    14
*
*---
*
SAVEAREA DS    18F
*
AEPA DS    A
EPA  DS    CL28
*
SWAPARMS SWAREQ MF=L
*
  CVT   DSECT=YES
*
  IEFJESCT
*
  IEFZB505 LOCEPAX=YES
*
  END


The following snippet of REXX came from an exec by Frank Clarke, it should be 
fairly easy to translate it to C(++):


ptr: return c2d(storage(d2x(arg(1)), 4))

stg: return storage(d2x(arg(1)), arg(2))

swareq: procedure
  if right(c2x(arg(1)), 1) \= 'F' then/* SWA=BELOW ?  */
return c2d(arg(1)) + 16   /* yes, return sva + 16 */

  sva  = c2d(arg(1))  /* convert to decimal   */
  tcb  = c2d(storage(21c, 4)) /* TCB PSATOLD  */
  tcb  = ptr(540) /* TCB PSATOLD  */
  jscb = ptr(tcb + 180)   /* JSCB TCBJSCB */
  qmpl = ptr(jscb + 244)  /* QMPL JSCBQMPI*/
  qmat = ptr(qmpl + 24)   /* QMAT QMADD   */

  do while sva > 65536
qmat = ptr(qmat + 12) /* next QMAT QMAT + 12  */
sva  = sva - 65536/* 010006F -> 06F   */
  end

return ptr(qmat + sva + 1) + 16

--
Robert AH Prins
robert.ah.prins(a)gmail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[John McKown]

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 because I've been told (not done myself) that
you can now, z/OS 2.3, embed assembler using __asm() in C++ for use in a
"normal" (LE) C++ program.

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RDJFCB function in C++

[Bernd Oppolzer]

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 moved above the line,
and to translate this handle to an address, you need the SWAREQ macro.

I ended up writing a wrapper for SWAREQ, usable from C, in ASSEMBLER.

Look here:


CSWAREQ  CSECT
*
*---
*
*    int cswareq (char *psva, char **ppjfcb);
*
*    PSVA IST DER ZEIGER AUF EIN SVA-HANDLE
*    (Z.B. DER JFBC-POINTER AUS DER TIOT).
*
*    ZU DIESEM SVA-HANDLE LIEFERT SWAREQ
*    DIE ECHTE ADRESSE (DER JFCB LIEGT IN DER SWA -
*    SCHEDULER WORK AREA -, DESHALB IST DAS ETWAS
*    KOMPLIZIERTER).
*
*    DIE ADRESSE DES JFCB WIRD IM ERFOLGSFALL AN
*    DEN AUFRUFER ALS 2. PARAMETER ZURUECKGEGEBEN.
*
*---
*
 STM   14,12,12(13)
 LR    11,15
 USING CSWAREQ,11
 LA    15,SAVEAREA
 ST    15,8(13)
 ST    13,4(15)
 LR    13,15
*
 L 4,0(1)  ADRESSE SVA
 L 5,4(1)  ADRESSE DES JFCB-POINTERS
*
 LA    6,EPA   ADRESSE EPA NACH AEPA
 ST    6,AEPA
 USING ZB505,6
 XC    SWAEPAX,SWAEPAX EPA INITIALISIEREN
*
 MVC   SWVA,0(4)
 SWAREQ FCODE=RL,EPA=AEPA,UNAUTH=YES,MF=(E,SWAPARMS)
*
 LTR   15,15
 BZ    RETOK
*
 XC    0(4,5),0(5)
 B RET
*
RETOK    DS    0H
 MVC   0(4,5),SWBLKPTR
*
RET  DS    0H
 L 13,4(13)
 L 14,12(13)
 LM    0,12,20(13)
 BR    14
*
*---
*
SAVEAREA DS    18F
*
AEPA DS    A
EPA  DS    CL28
*
SWAPARMS SWAREQ MF=L
*
 CVT   DSECT=YES
*
 IEFJESCT
*
 IEFZB505 LOCEPAX=YES
*
 END

HTH, kind regards

Bernd



Am 05.02.2018 um 17:29 schrieb Patrick Roehl:

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 / 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: RDJFCB function in C++

[Charles Mills]

As an experienced exploiter of that *type* of z/OS function from C++, but not 
having researched the specific problem, I will say that if I faced that need I 
would *probably* write a little assembler routine to issue RDJFCB and return 
the results to C++.

Not having researched it, some of the 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 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 / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN