I think I understand. AFAIK JES(2) will accept any DESTID as long as it's syntactically correct and does not conflict with other names. For example, NnRn is an implicit DESTID for node-n remote-n. You don't need to define it and I believe cannot define it because it's automatically recognized. Other than that, I don't know of any restriction. DEST=TONYH should cause no problem. An output segment so designated will wait in spool for 'instructions' on what to do.
A DESTID does not itself involve 'allocation'. It's just a label that JES(2) attaches to an output segment. If some process wants to actually allocate, say, a file containing your DESTID as part of the DSN, then that program may impose its own rules on DESTID apart from any JES(2) restrictions. The example you gave and associated APAR come not from JES(2) but from something called OUTPUT MANAGER. My guess is that OUTPUT MANAGER is particular about names in a way that JES(2) is not. I would be very interested to see a case where JES(2) rejects a DESTID, but in the meantime I'm inclined to believe that there is no restriction other the one(s) I mentioned above. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile [email protected] > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Tony Harminc > Sent: Friday, January 29, 2016 08:27 AM > To: [email protected] > Subject: [Bulk] Re: [Bulk] Re: [Bulk] Re: IEFSSREQ SSOBUSER Validate A JES2 > Destid > > On 29 January 2016 at 01:09, Skip Robinson <[email protected]> > wrote: > > It's curious that you're getting this message if you do not have the issuing > product installed. Search on IBM ServiceLink shows this: > > > > OUTPUT MANAGER FOR Z/OS 210 > > or > > TIVOLI OUTPUT MANAGER > > I guess I was unclear; I'm not getting this message. I was trying to make the > point that there exists (and has roughly forever) a dynamic allocation message > that complains the destination is not known to the subsystem. And > furthermore there is a recent APAR describing some IBM product that > provokes the message by (in error) passing in a bad destination. If JESx > accepts > any old destination without validating it, then why does this message (and > indeed the whole subsystem interace for validating destinations) exist? > > Well maybe JES2 (in my case) has changed over the years. But I can remember > getting the message on TSO decades ago. > > Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
