Here it is
As it was recommended to issue SCHEDIRB From an IRB I issue it from a STIMER
routine
I'll start with the STIMERM I use STIMERM as opposed to STIMER because it lets
my pass a parameter (which is the save area for 13)
STIMERM SET, X
ID=TIMER, X
BINTVL=NOW, X
ERRET=ERROR, X
EXIT=STIMER, X
PARM=TIMER_PLIST, X
WAIT=NO,MF=(E,TIMERLST)
STIMER DS 0D
STM R14,R12,12(R13)
*
LR R4,R15
DROP R3
USING STIMER,R4
LR R10,R13
L R13,4(,R1) Get Save area
DROP R13
USING TIMERSVE,R13
ST R10,4(R13)
*
SETLOCK OBTAIN,TYPE=LOCAL,MODE=UNCOND,REGS=SAVE
*
*
* Chain rb pointer to put this IRB as next
*
LA R5,IRBPTR
O R5,=X'80000000'
ST R5,IRBADD
L R6,PSATOLD
USING TCB,R6
L R6,TCBJSTCB Get the Job Step tcb
ST R6,JSTCB
SCHEDIRB EPPTR=IRBADD, X
TCBPTR=JSTCB, X
SVAREA=YES, X
MODE=SUPR, X
KEY=SUPR, X
PARAMPTR=PLIST, X
MF=(E,IRBLST)
SETLOCK RELEASE,TYPE=LOCAL,REGS=SAVE
*
*
L R13,4(,R13)
XR R15,R14
L R14,12(R13)
LM R0,R12,20(R13)
BR R14
DROP R13
USING WORKAREA,R13
DROP R4
IRBPTR DS 0D
*
STM R14,R12,12(R13)
LR R5,R15
USING IRBPTR,R5
LR R10,R1 Save Plist pointer
LOAD EP=GETVECT
ST R0,0(R10) Store Pointer
XR R15,R15
L R14,12(R13)
LM R0,R12,20(R13)
BR R14
DROP R5
WORKAREA DSECT
SAVEAREA DS 18F
TIMERSVE DS 18F
DS 0D
TIMER DS F
PARMPTR DS A
FADDR DS A
DEPARM DESERV MF=L
CSVLMPEA DS CL(LPMEA_LEN)
DELEN EQU *-DEPARM
SCHEDIRB MF=(L,IRBLST)
CSVQUERY MF=(L,CSVQUERY)
TIMERLST STIMERM SET,MF=L
PLIST DS 0A
DS A
TIMER_PLIST DS A
DESPTR DS A
IRBADD DS A
JSTCB DS A
T
T
T
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Seymour J Metz
Sent: Tuesday, September 19, 2023 8:02 PM
To: [email protected]
Subject: Re: Why it's important to take Seymour's advice
Show the code.
________________________________________
From: IBM Mainframe Discussion List <[email protected]
<mailto:[email protected]> > on behalf of Joseph Reichman
<[email protected] <mailto:[email protected]> >
Sent: Tuesday, September 19, 2023 7:58 PM
To: [email protected] <mailto:[email protected]>
Subject: Re: Why it's important to take Seymour's advice
I am looking at the TCB/rb chain in the SVC dump the IRB epa has a 1 as the
last digit I was in amode 31 when I issued schedirb The irb address last digit
was a 0 before it pc to schedirb
At this point I’m thinking of using the crib macro to build the irb as it gives
me more control ie I can look at the irb before it goes to schedirb
Thanks
> On Sep 19, 2023, at 4:20 PM, Seymour J Metz <[email protected]
> <mailto:[email protected]> > wrote:
>
> It's best to use whichever is fitted to the task at hand. There is no one
> size fits all.
>
> ________________________________________
> From: IBM Mainframe Discussion List <[email protected]
> <mailto:[email protected]> > on
> behalf of Joseph Reichman <[email protected]
> <mailto:[email protected]> >
> Sent: Tuesday, September 19, 2023 12:53 PM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: Why it's important to take Seymour's advice
>
> Hi just did a a SUMM TCBERROR and this is what I got
>
> Now I was doing something in AMODE 64 prior to the SCHEDIRD But I know
> I went back to AMODE 31
>
> As an side is it better to USE CRIB to schedule the IRB (in which
> case it returns to me the IRB and I can see what I am scheduling or )
> SCHEDIRB
>
> Thank you
>
> IRB: 008FB710
> KEYSTA... 00 WLIC..... 00040004 EPA...... 9FF01E81
> OPSW..... 078D0000 9FF01EA0 LINK..... 008FEA90
>
> PRB: 008FEA90
> WLIC..... 00020001 OPSW..... 071C1000 852CB728
> LINK..... 018E76D0
> EP....... IKJEFT01 ENTPT.... 852C5000
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]
> <mailto:[email protected]> > On
> Behalf Of Lennie Dymoke-Bradshaw
> Sent: Tuesday, September 19, 2023 11:25 AM
> To: [email protected] <mailto:[email protected]>
> Subject: Re: Why it's important to take Seymour's advice
>
> My experience is that in times past this was definitely true. But nowadays it
> no longer is.
> I am unsure what changed but I think there was a change somewhere, possibly
> in the cross-memory instructions.
> Lennie
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]
> <mailto:[email protected]> > On Behalf Of [email protected]
> <mailto:[email protected]>
> <mailto:[email protected]>
> Sent: 19 September 2023 16:16
> To: [email protected] <mailto:[email protected]>
> <mailto:[email protected]>
> Subject: Re: Why it's important to take Seymour's advice
>
> I think the other address space needs to be nonswappable.
>
>
>> On Tuesday, September 19, 2023 at 09:40:36 AM EDT, Adam Johanson
>> <[email protected]
>> <mailto:[email protected]
>> <mailto:[email protected]
>> <mailto:[email protected]> > > wrote:
>>
>> Tom Brennan wrote:
>>
>> I've never written code that runs as an SRB, but over the years I've
>> read about them and seen them in action, such as Omegamon poking code
>> into other address spaces to grab data or do things like zap memory.
>
> For what it's worth, you don't need to go through all the rigamarole of an
> SRB to go poking around in another address space.
>
> Given the proper authorization, you can:
>
> - Issue an AXSET, specifying a value of 1
> - Issue an SSAR instruction identifying the target address space as
> the secondary address space
> - Use MVCP / MVCS instructions to copy data between your primary
> address space and the secondary address space
>
>
> There is also the technique of using the special ALET value of x'00000001'
> and using AR mode to reference data from another address space.
>
> ===============================
> Adam Johanson
> Broadcom Mainframe Software Division
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] <mailto:[email protected]>
> <mailto:[email protected]>
> with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] <mailto:[email protected]>
> <mailto:[email protected]>
> with the message: INFO IBM-MAIN
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] <mailto:[email protected]>
> <mailto:[email protected]>
> with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] <mailto:[email protected]> with the
> message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] <mailto:[email protected]> with the
> message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] <mailto:[email protected]> with the message:
INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] <mailto:[email protected]> with the message:
INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
