Hi there,
let me put some light on the process so you can understand what we are doing (me an Alan).
1) Try to send emails from OPS ( didn't work until set OSFGETJOBID to YES )
2) Shutdown the LPAR with OSFGETJOBID set to YES ( JES2 HANG )
here is how the shutdown process work;
A REQ rule traps the shutdown command issued in the console and gets a REXX called SHUTTST1 to issue SSM STOP commands to bring everything down.
When everything is almost down, the SSM STOP JES2 is issued. STCTBL_ACT points STOP JES2 to a rexx called JES2ABND. When it goes down, shutdown proceed until GDPS takes over and IPL the hole thing.
I had updated the JES2ABND with the sample thrasmus placed above on the thread, all the OSF got recycled except for ONE ( the REQ.RULE SHUTTST1 ). Even with the parm set to NO, that one that was activated prior JES2ABND runs (prior the parm be set to NO) still hold JES2.
That is why I came with the SUB=MSTR idea, to have all the OSF-SERVER running outside JES2. Is there a way to customize them that way, so we can re-test ?
Where is the best place to put the sample from thrasmus in this entire process ?
Thanks
Original Message:
Sent: 06-04-2020 01:05 PM
From: Carlos Mario Silveira Filho
Subject: Sample exec EMAILTXT
Hi Alan,
The job ids are acquired or released at the time the REXX program is dispatched to the OSF server.
So, if you set OSFGETJOBID to NO before you run this REXX the server where it is running won't have a job id assigned.
Regards,
Mario
Original Message:
Sent: 06-04-2020 12:52 PM
From: Alan Schwartz
Subject: Sample exec EMAILTXT
After customize the OSFGETJOBID to YES in order to submit emails, the admin had to customize the way JES2 is shut down. Have to set OSFGETJOBID to NO again, then recycle all the OSF SERVERS. Thing is, the OSFSERVER that is running the code to stop them all is activate and doesn't recycle. That bring me issues since that one holds JES2. Is there a way to start OSFSERVER as SUB=MSTR ? that way I can still use OSFGETJOBID as YES but avoid shutdown problems ?
Original Message:
Sent: 04-17-2020 10:18 AM
From: TIM RASMUSSEN
Subject: Sample exec EMAILTXT
For 20+ years we have used this process:
rtncd = opsprm('SET','OSFGETJOBID','NO')
z = opswait(2)
address 'OPSCTL'
'osf list'
do queued()
parse pull asid therest
address 'OPSCTL'
'osf stop' asid
end
This OPSREXX program (OSFDELID) is executed as part of the JES2 shutdown process since OPS/MVS is one of the last started tasks shutdown on each system. It has worked great.
Original Message:
Sent: 04-17-2020 09:41 AM
From: Carlos Mario Silveira Filho
Subject: Sample exec EMAILTXT
Hi Alan,
Yes, this may be a concern but I wouldn't say a "risk". If you change the value of OSFGETJOBID to YES you should include a command to set it back to NO in the system shutdown procedure. That would be a statement like below:
rc=Opsprm('SET','OSFGETJOBID','NO')
You may also need to recycle the OSF server after this change depending on the number of servers and how much they are active as they will release the jobid when a REXX is scheduled to run.
Regards,
Mario
Original Message:
Sent: 04-17-2020 09:07 AM
From: Alan Schwartz
Subject: Sample exec EMAILTXT
Thanks Carlos.I checked my OPS parameters and OSFGETJOBID is set to NO. There are some comments above it from a previous technician - gone for a number of years.
OSFGETJOBID was changed to YES, but then JES2 wouldn't shutdown until server cancelled, so we changed it back to NO.
If you change this parm, you *MUST* bounce the servers.
May I assume this is no longer a risk?
Alan
Original Message:
Sent: 04-16-2020 07:10 PM
From: Carlos Mario Silveira Filho
Subject: Sample exec EMAILTXT
Hi Alan,
In order to be able to run this exec or any other REXX program that requires JES services you need to set the parameter OSFGETJOBID to YES.
See the reference to this parameter in the link below:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-mainframe-software/automation/ca-ops-mvs-event-management-and-automation/13-5/reference-information/parameter-reference/parameters-for-facilities/osf-parameters.html#concept.dita_170ffc54c774cb78ecb1e992b38e6afbec696df8_OSFGETJOBIDParameter
Regards,
Mario
Original Message:
Sent: 04-16-2020 03:56 PM
From: Alan Schwartz
Subject: Sample exec EMAILTXT
We run OPS/MVS as a subsystem. We started playing with sample exec EMAILTXT. The allocation in the exec is
address OPSDYNAM "ALLOC FI(PUNCH1)",
"SYSOUT(B) WRITER(SMTPMVS3)"
This fails with:
$HASP708 OPSOSF ???????? OPEN FAILED
RC=13 SDB/IRWD VALIDATION ERROR
IEC141I 013-C0,IGG0199G,OPSOSF,OPSOSF,PUNCH2
IEF196I IEC141I 013-C0,IGG0199G,OPSOSF,OPSOSF,PUNCH2
ERROR DESCRIPTION: IEC141I
IEC141I 013-C0 has a number of possible causers. The one that seems most likely is:
"A SYSIN or SYSOUT data set opened under the master subsystem"
We could try a dataset but in a multi-processing system like OPS/MVS I can see all sorts of serialization problems.
So how do we get around allocating some place to store the message being built when OPS/MVS runs SUB=MSTR?
Alan