***ERROR - DSS4500E - INVALID DATA SET NAME FORMAT IN DSN= OPERAND
I would guess what is happening here is that the DSN is over 44 characters long - I presume this is still a limit - and JEM is trying to tell me that in different ways. Note that JEM resolved the DD DSN but not the SYSIN name.
I spent quite some time looking for DSS (Data Storage System?) messages but to no avail - i.e. DSSnnnna messages.
I looked at LookAt (http://www-03.ibm.com/systems/z/os/zos/bkserv/lookat/) for instance but also elsewhere. When I saw a list of message manuals I gave up since there doesn't seem to be any documented DSS messages, as implied by these message titles:
SA22-7634 z/OS MVS System Messages, Vol 4 (CBD-DMO)
SA22-7635 z/OS MVS System Messages, Vol 5 (EDG-GFS).
Can anyone say differently or tell me that the messages above aren't complaining about the length of the DSN?
This is using IEFBR14, so I'd expect it to work for any DD statement in a JCL deck. Haven't tried it any other way.
z/OS V1R11 DFSMS Using Data Sets
wrote:
A data set name can be from one to a series of twenty-two joined name segments. Each name segment represents a level of qualification. For example, the data set name DEPT58.SMITH.DATA3 is composed of three name segments. The first name on the left is called the high-level qualifier, the last is the low-level qualifier.
Each name segment (qualifier) is 1 to 8 characters, the first of which must be alphabetic (A to Z) or national (# @ $). The remaining seven characters are either alphabetic, numeric (0 - 9), national, a hyphen (-). Name segments are separated by a period (.).
Data set names must not exceed 44 characters, including all name segments and periods.
The "now" I was referring to was against when I first used MVS :-)
This is a belated entry that I composed over a week ago but wasn't able to post it because of logon problems.
The DSS messages are not from IBM but, on our system, reside in a non-system PARMLIB, the member being DSSMSG00, and the parmlib is coded in all of the JCL checker objects (CLISTS).
In SYS1.TSOCMDS we have these JCL checkers: JEM, JSCAN, and JOBSCAN; and if you look at the programs called in these members, and browse the programs in the loadlib (also mentioned in the TSOCMDS members) then you’ll see that the organisation mentioned in the load members is the Allen Systems Group, Inc., also known as ASG Software Solutions, 1333 Third Avenue South, Naples, FL 34102. A bit more digging reveals that this company bought out another: “June 12, 2006 -- ASG, an enterprise software provider to Global 5000 companies, today announced it has sealed a deal to acquire Diversified Software Systems, Inc. (DSSI), a leading provider of JCL automation software products and services based in Morgan Hill, California.” (DSSI is defunct but one can still find current references for DSSI Inc., for instance in the Cortera Business Directory, but the address given (and using Google Maps) is clearly another company: Dividend Homes, 385 WOODVIEW AVE, STE 50, MORGAN HILL, CA, 950372891 US.). With DSSI as the original developer, it doesn’t take a rocket scientist to figure out where the DSS prefix in the messages comes from.
In SYS1.TSOCMDS the three JCL checkers refer to the following programs, and the provenance of the programs can be discovered by browsing:
JOBSCAN calls J00YDMU, which is credited to ASG, Inc., 2009;
JSCAN, in a section commented with “ALLOCATE RUN CONTROL LIBRARY”, calls J00YCKAL, which is credited to DSSI, Inc., 1995; and in a section commented with “RUN JOB/SCAN” it calls J0AYEMU, which is credited to ASG, Inc., 2008;
JEM, in a section commented with “ALLOCATE RUN CONTROL LIBRARY”, calls J00YCKAL, which is credited to DSSI, Inc., 1995; and in a section commented with “CALL THE JEM SUPERVISOR” it calls J0AYEMU, which is credited to ASG, Inc., 2008.
One last thing – on ASG's website they state:
“ASG-JOB/SCAN, a JCL validation and standards enforcement product, is specifically designed to help single LPAR data centers (with COBOL or Assembler expertise for JCL standards programs) operate an error-free production JCL environment. If your organization's data resides on a single LPAR, ASG-JOB/SCAN will validate the production JCL – processing the entire JCL jobstream, resolving backward references, substituting symbolics, applying overrides, and then evaluating each statement for accuracy according to standard z/OS syntax rules.”
I'm not au fait with LPARs (I think they’re a bit like Apple's BOOTCAMP in OS X 10.6 – i.e. a hardware division of the machine enabling multiple OS's), but don't most (or, at least, many) IBM installations run multiple LPARs? And what is the issue with restricting the scanning software to one LPAR? If LPARS are like Apple's BOOTCAMP then there will be separate system software for each LPAR, so, for instance, a separate Master Catalog; hence, logging on to a system with LPARs is like logging on to a single system,except there could be sharing of volumes, hence data, in multiple LPAR systems. But, of course, sophisticated techniques would be used to handle simultaneous requests for the same data, so what's the problem - is the statement correct on the point of only being able to operate in a single LPAR system (which I take to mean an undivided hardware system)?
P.S. An afterthought: when you look through the DSS messages they tell you which actual IBM message has been returned, and a DSS message can be associated with many IBM messages. But the scan will have been returned a specific IBM message, so why doesn't the scan display the actual IBM message – is ASG contractually prevented or is a message usage royalty to be paid?
P.P.S. The DSS messages can be expanded by issuing the command: JMSG line tag, e.g. JMSG .JAAA.