How could I determine if APPC output is clogging my spool? I don't see any at the moment.
. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: Saturday, June 18, 2016 6:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Where is format of Job ID documented? We always auto-purged older held output known to be past its usefulness and for some categories of output that usefulness was a matter of hours not days. My recollection is that after APPC came upon the scene we had to modify the held-output purge command sequences or APPC output wasn't touched. Makes me wonder if the folks seeing terrible performance when SDSF shows APPC output could be unintentionally retaining APPC junk in their output queue that has no useful function and which would be better to purge in a more timely fashion. Joel C Ewing On 06/17/2016 02:11 PM, Jesse 1 Robinson wrote: > In the case of (2), Mark Zelden already explained why most of us have never > seen Annnnnn. His post reminded me of the severe performance problem when > including APPC output. That goes back a long way, and I don't know if it's > still a problem, but I agree with him that most shops have turned off APPC > stuff SDSF either by old practice or by ongoing default in SDSF. > > I really wonder if 'O' is ever used. When I submit a job to pull sysmods from > Shopz, I can see in DA up to two additional tasks running at the same time > presumably to handle the USS work. They are never called 'O' or 'U' anything. > And there's 'no displayable data' when they're selected. > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-302-7535 Office > robin...@sce.com > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Charles Mills > Sent: Friday, June 17, 2016 10:59 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Where is format of Job ID documented? > > Thanks. Dr. Merrill came closest to the answer I was looking for. The real > question behind the question was "if I am processing JOB ID's what should I > expect to see, and if I am presenting them to people who have never heard of > JES, what should they expect to see and what does it mean?" > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Tony Harminc > Sent: Friday, June 17, 2016 10:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where is format of Job ID documented? > > On 15 June 2016 at 16:38, Charles Mills <charl...@mcn.org> wrote: > >> Yeah, I know, JOBnnnnn or Tnnnnnnn. >> >> Is there a formal description somewhere? Where? >> > It seems to me there are at least two quite different questions here: > > 1) What is the acceptable syntax for a Job ID? > > 2) What formats are seen "in the wild", and perhaps > > 3) What are the circumstances in which each can be generated? > > I think the answer to (1) is straightforward: The (perhaps obsolescent but > still valid) description of a Job ID as supported by TSO's IKJPARS is "The > jobname can have an optional job identifier. Each job identifier is a maximum > of eight alphanumeric characters, the first of which must be an alphabetic > character or one of the special characters $, #, @." So the TSO commands > CANCEL,STatus, and OUTput will enforce this, and perhaps others will too. > Whether anything in the MVS Subsystem Interface enforces these rules I don't > know, but I'd guess it's very unlikely. How it would return an indication of > invalidity is one question, aside from the general un-SSIness of checking. So > then of course each Job Entry Subsystem can do whatever it likes as fas as > checking/enforcing, and those rules will presumably be stricter than the > basic syntax. > > (2) has been much discussed already. I must say I've never seen an > Annnnnnn-format Job ID, but surely APPC is more than obsolescent now, and has > been for many years. In theory anyone can write a JES, and that JES could > have whatever rules it likes, but in practice I don't think anyone is really > going to be writing a JESx except perhaps as a learning exercise. > > (3) is a matter of anecdotes combined with actual knowledge of the code. > Job IDs are generated by various programs, and can also come in off > the wire via NJE. Remotes systems such as RSCS don't have the concept > of a Job ID, so normally JES2 generatoes a J-type one of its own. If > there is an inbound one that doesn't match the rules, then what? I > don't know, but it shouldn't be hard to find out. Ah - looking at the > NJE headers reminds me that it's a binary (16-bit!) job *number* that > comes in, and then JES2 has bit flags to say that it's a batch job or > a started task. No TSO... Anyway ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
