of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, December 17, 2020 4:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx APIs (was: IODF address)
On Thu, 17 Dec 2020 19:46:13 +, Seymour J Metz wrote:
>Or at least a function to return the current addr
On Thu, 17 Dec 2020 19:46:13 +, Seymour J Metz wrote:
>Or at least a function to return the current address of a string variable,
>plus some way to control alignment.
>
I've pondered something similar in connection with wishing for a
variant of ATTACH that would leave the subtask running
Seems to me you'd get almost all the benefit with little effort to just
write a simple program that LINKMVS could call to LOAD a module. That
would keep it in storage for subsequent calls by LINKMVS, etc. Goes w/o
saying it would need to be marked REUS at least.
If the actual overhead of LINK
Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, December 17, 2020 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Rexx APIs (was: IODF address)
On Thu, 17 Dec 2020 18:47:27 +, Seymour J Metz wrote:
>I know of no REXX facility to enumerate environments, but z/OS Versio
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, December 17, 2020 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx APIs (was: IODF address)
Re: your
to accomplish it.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
Sent: Thursday, December 17, 2020 2:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Rexx APIs (was: IODF address)
EXTERNAL EMAIL
On Thu, 17 Dec 2020 18:47:27 +, Seymour J Metz wrote
On Thu, 17 Dec 2020 18:47:27 +, Seymour J Metz wrote:
>I know of no REXX facility to enumerate environments, but z/OS Version 2
>Release 4 TSO/E REXX Reference describes the relevant environment, LINKPGM.
>
LINKPGM, which is essentially Assembler LINK macro, works well
for such as ICSF; less
@LISTSERV.UA.EDU] on behalf of
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, December 17, 2020 12:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IODF address
On Thu, 17 Dec 2020 15:59:45 +, Seymour J Metz wrote:
>Look at the address statem
On Thu, 17 Dec 2020 15:59:45 +, Seymour J Metz wrote:
>Look at the address statement and at the descriptions of the available
>environments.
>
Is there a Rexx facility to enumerate "available environments"? I suspect not,
but it
would be a good CbtTape.org candidate.
ADDRESS SYSCALL has a
...@gmail.com]
Sent: Thursday, December 17, 2020 7:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IODF address
Thanks Rob!
I think it's just ignorance on my part, but I haven't had much luck calling
assembler services from Rexx - only some of those mentioned in the
"Callable Services for High Level Lang
IOCINFO IODFINFO=xx
If success and bit IODI_IODFUCBInvld is off, the UCB address is in
IODI_IODFUCB and the device number can be ascertained from that.
Peter Relson
z/OS Core Technology Design
--
For IBM-MAIN subscribe /
Mainframe Discussion List On Behalf
> Of Steve Horein
> Sent: 16 December 2020 17:00
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IODF address
>
> EXTERNAL EMAIL
>
>
>
>
>
> Hi!
> I am able to determine the IODF unit address from IPAIODFU in IPA.
> However, t
I don't have all the technical details, but there tends to be occasional
DASD movement where FDRPAS is used to non-disruptively "move' the contents
of a volume from one unit address to another.
Where I fit in is I have written a (rexx based) automation routine that
displays old/current IPL
DFUCBINVLD is
OFF)
Mapping macro is IOSDIODI in MACLIB
Rob Scott
Rocket Software
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Horein
Sent: 16 December 2020 17:00
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IODF address
EXTERNAL EMAIL
Hi!
I am able to determin
Just me being dumb.. what do you mean by 'IODF volume moved'?
- KB
‐‐‐ Original Message ‐‐‐
On Thursday, December 17, 2020 10:06 AM, Steve Horein
wrote:
> Thanks!
> It looks like I get the same behavior with what Mark uses:
>
> IPALPDDV = Storage(D2x(ECVTIPA + 92),4) /* load parm dev
Thanks!
It looks like I get the same behavior with what Mark uses:
IPALPDDV = Storage(D2x(ECVTIPA + 92),4)/* load parm dev number */
On a system that had the IODF volume "moved", the old address is also
present in IPALPDDV. Bummer.
On Wed, Dec 16, 2020 at 8:15 PM kekronbekron <
Hi Steve,
This should be in Mark Zelden's IPLINFO source code -
http://www.mzelden.com/mvsfiles/iplinfo.txt
- KB
‐‐‐ Original Message ‐‐‐
On Wednesday, December 16, 2020 10:29 PM, Steve Horein
wrote:
> Hi!
> I am able to determine the IODF unit address from IPAIODFU in IPA. However,
Hi!
I am able to determine the IODF unit address from IPAIODFU in IPA. However,
this value becomes stale if the address changes when the storage folks move
disk around. I can see the MVS command DISPLAY IPLINFO accounts for those
changes in message IEE254I:
IEE254Ihh.mm.ss IPLINFO DISPLAY
18 matches
Mail list logo
