Sample exec EMAILTXT

[Deactivated User]

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

[Carlos Filho]

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

[Deactivated User]

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

[Carlos Filho]

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

[Deactivated User]

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.

[Deactivated User]

Thanks both. Our primary OPS admin will be out next week on a forced vacation so I won't be able to pursue this until he comes back. We'll stick in OPS in one of our test lpars so we can see how shutdown looks. Stand by and keep your distance.
Alan

[Deactivated User]

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 ?

[Carlos Filho]

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

[Deactivated User]

We're wondering if OPSOSF can run as a subsystem. SUB=MSTR when started.
Alan

[Carlos Filho]

Hi Alan,

If OPSMAIN was started with SUB=MSTR then the OSF server will also be started under the master subsystem.
This is why you need the OSFGETJOBID parameter set to YES so that they get a job id to run JES related functions.

Regards,
Mario

[Renato Villalba]

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

[Carlos Filho]

Hi Renato,

My suggestion is that you change the OSFGETJOBID to NO before you call the first REXX that performs the shutdown. You can set it in the CMD rule that initiates the whole shutdown process so when the first REXX is called OSFGETJOBID is already NO.
The rest of the code to recycle the OSF servers can remain in the same place you have now, it is just the instruction to change the OSFGETJOBID parameter that I'm suggest you issue it earlier.

Regards,
Mario