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
