I'm having a devil of a time trying to merge VSAM datasets. The problem is that the names of the datasets change daily, fortunately the names are stored in a file that I can access. So, what I did (and it worked during testing) is to create a file with ALLOCATE and REPRO commands, then take that file into IDCAMS.
The problem I am having, and know of no way around, is that the ALLOCATE command prefixes the file names with the job's user name, REPRO takes the name as it is entered.
According to Knowledge Center the prefix can be overridden with the USER parm in the JOB card, but USER has to be a valid user ID, not something generic like TEST. REPRO, as far as I can tell, has nothing similar. So I end up with:
ALLOC (MY.FILE) creates MYID.MY.FILE
REPRO only sees MY.FILE, there seems to be no way to get MYID into the front of the file name.
Does anyone have any ideas on how to get around this?
Joined: 30 Nov 2013 Posts: 585 Location: The Universe
Let me be more specific, the manual says
If the USER parameter is not in the JCL, no prefix is added to any data set name given by ALLOCATE.
I don't have a USER parameter in my JCL, but the ALLOCATE is still picking it up.
Unless the job is submitted from a real card reader (remember those?) the job is assigned to the implicit userid of the submitting job or TSO session. Yes, you can specify a different user, but you cannot specify no user.
The IDCAMS ALLOCATE command is not really an IDCAMS command. It is really a TSO command. The IDCAMS manual clearly states this.
Access method services identifies the verb name ALLOCATE and attaches the terminal monitor program (TMP) that runs Time Sharing Option (TSO) commands in the background. The ALLOCATE command should be used only to allocate new data sets to the job step. If you use ALLOCATE through access method services for anything else (the handling of SYSOUT data sets, for example), you can get unpredictable results. Refer to z/OS TSO/E Programming Guide for additional information on using this command. Table 2 in topic 4.5 separates the parameters to that you should use under access method services from the parameters that cause unpredictable results.
As in TSO, if you do not want the standard prefix added to a data set name specified in most TSO command lines, you use single quotes around the data set name.
ALLOCATE FILE(SYSLIB) SHR DATASET('SYS1.MACLIB')
For consistency you can use this method with batch IDCAMS commands.
Joined: 30 Nov 2013 Posts: 585 Location: The Universe
That worked! Thank, Steve.
Like I said, I could swear I read somewhere that you can't use quotes in IDCAMS, obviously I was wrong.
Actually, I have a similar problem; I don't know where it says you can use quotes for a data set name or something similar.
I am guided in this by two thoughts.
When IDCAMS was originally defined, its command syntax seemed to be guided by TSO command syntax.
At some point – I really don't know when -- many IDCAMS commands were made TSO line mode commands. In fact, they replaced some TSO commands, like DELETE and LISTCAT. I do know when IDCAMS commands are invoked as a TSO command the syntax error messages appear to be messages from IKJPARS, the TSO service used to process command lines, rather than whatever IDCAMS function that processes its command lines.
I had to RTF(several)M to see what the rules are around quoted dataset names out of curiosity. Very rarely I have come across anomalous dataset names that contain strange characters including blanks for example and wondered how they were created. They can only be NONSMS, and could only be deleted by putting the names in quotes. They usually come to light because some ISV product abending or complaining about the invalid name.
Pre-SMS I 'think' you could create those by having the names in quotes in your JCL, but now SMS will reject them if coded in JCL. But according to the quote from the 'Using Data Sets' manual below it may still be possible when using Dynalloc if the DSNCHECK is not enabled in CAS.
The following rules apply to naming data sets:
v If quotation marks delimit a data set name in a JCL DD statement, JCL
processing cannot perform syntax checking on the statement, and SMS rejects
the input based on its parsing of the data set name. SMS does not allow the
name to be catalogued because quoted data sets cannot be SMS managed.
v IDCAMS does not allow the specification of non-valid data set names.
v When you invoke Dynamic Allocation services or directly invoke SVC 26, it is possible to create data set names that are not valid. When the CATALOG routine is called to add the data set to a catalog, there is no way to determine whether the original name was in JCL or whether quotation marks delimit the name. The catalog component validates the syntax of a data set name and fails the request if the syntax is not valid, unless the syntax-checking option for data set names is off. See the description of the MODIFY CATALOG command's DSNCHECK parameter in z/OS DFSMS Managing Catalogs.
PS: In 'DFSMS AMS for Catalogs' it does mention use of quotes for the allocate command:
If the data set name is not in quotation marks and a USER parameter is
given in the JCL, the value in the USER parameter is prefixed to all data set
names given by ALLOCATE.
ALLOCATE was a relatively recent addition to IDCAMS, perhaps 10-15yrs or so ago, I can't remember. May have been with DFP3.1 that introduced a lot of new support for SMS.
Access method services identifies the verb name ALLOCATE and attaches the terminal monitor program (TMP) that runs Time Sharing Option (TSO) commands in the background. The ALLOCATE command should be used only to allocate new data sets to the job step. If you use ALLOCATE through access method services for anything else (the handling of SYSOUT data sets, for example), you can get unpredictable results.