When I was designing our SyzMail/z product I had briefly considered using JES2 as the conduit for the mail, but discarded it because of the (many) issues I ran into when trying to implement this via the JES interfaces. What I discovered was a way to produce the email without JES being involved and without requiring any JCL changes to have it happen. It turned out that I didn't even need to force the job to have a notify= on the jobcard.
You have not even gotten into the major problem areas that I foresaw in setting this all up through JES yet. They likely saw what I did and have the extra address space because you can't really have JES itself waiting on SMTP, but they are still left with the connection issues between the output processors and that space. My way completely removed the connection and doesn't even depend on it being JES2, any spooler will do (JES3, etc.). I'm sure that IBM will eventually get the bugs worked out, but there implementation isn't really a danger for us (product sales wise), and our method is patented so when they work out that there is a "better" way, we will probably hear from them. :) Several of our past products are now part of the system, one more won't hurt. Brian On Mon, 26 Feb 2018 15:37:45 -0600, Dennis Schaffer <[email protected]> wrote: >I want to inform the JES2 community of a problem which has bitten us in >testing JES2 v2.3. > >There's a new feature, called JES2 Email Delivery Services (EDS) in JES2 v2.3, >which is intended to allow delivery of NOTIFY messages to an email address. >The function is documented in a new manual: >https://www-304.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3izsh100/$file/izsh100_v2r3.pdf. > The key point, for this problem, is started task JESxEDS (where x is the >identifier for the instance of JES2; 2, in our case) > >The symptom for our problem was inability to shutdown JES2 via $PJES2 (which >is normal for us) or $PJES2,TERM (which is abnormal for us); a $PJES2,ABEND >was required. IBM eventually determined that JES2 was waiting for stc JES2EDS >(in our case) to shutdown. Furthermore, JES2 had either remembered that >JES2EDS status across JES2 Quick starts or tried to restart JES2EDS during >each JES2 initialization. But, since JES2EDS had never really started, it >couldn't shutdown and JES2 waited indefinitely for an event which would never >happen. > >The need for JES2 to start JES2EDS was triggered two days after we implemented >JES2 2.3 in this environment, when a user submitted a job containing this >statement "//LABEL NOTIFY USER=userid,TYPE=EMAIL", one of the triggers for >this new EDS function. When JES2 executed this job, it attempted to create an >email notification for this user and start JES2EDS. Unfortunately, we hadn't >defined a RACF userid for JES2EDS yet and it failed to start. JES2, however, >assumed that JES2EDS started normally and that set in motion the problems we >experienced when we tried to shutdown JES2 a week later. > >In our case, IBM asked us to define RACF uid JES2EDS and to issue command "$S >EDS" to request a start of JES2EDS. Based on dumps we took later, IBM told us >that didn't really get JES2EDS started but it cleared the PCE wait flag which >$PJES2,TERM had been waiting on; they think JES2EDS will start with the next >JES2 initialization. IBM told us there really isn't a mechanism (a $D EDS >command) to inquire the status of JES2EDS. We also weren't able to see >address space JES2EDS (via D A,JES2EDS) after issuing "$S EDS" and IBM told us >they saw the same (or lack thereof) on their system when they tried the same; >however, that may have happened because JES2EDS really didn't start after "$S >EDS". > >The key circumvention for this problem is to do whatever is necessary to allow >JESxEDS to start; at a minimum, create a RACF userid for the task with at >least minimal permissions to access SYS1.LINKLIB. I'd recommend all JES2 2.3 >shops create this UID until the fix for this problem is available, even if you >don't think you're using the EDS function. We didn't think so, either. > >IBM has written APAR OA55008 for this problem. > >Please let me know if you have any questions. > >Thanks, >Dennis > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [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
