View previous topic :: View next topic
|
Author |
Message |
pahiker
New User
Joined: 10 Aug 2012 Posts: 51 Location: USA
|
|
|
|
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? |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
if You are using idcams , the manual will tell how to get rid of the prefix
if You are running the allocate thru TSO then PROFILE NOPREFIX will do |
|
Back to top |
|
|
pahiker
New User
Joined: 10 Aug 2012 Posts: 51 Location: USA
|
|
|
|
enrico-sorichetti wrote: |
if You are using idcams , the manual will tell how to get rid of the prefix
if You are running the allocate thru TSO then PROFILE NOPREFIX will do |
I read the manual (KC) and could not find a way to get rid of the prefix, which is why I posted here. |
|
Back to top |
|
|
pahiker
New User
Joined: 10 Aug 2012 Posts: 51 Location: USA
|
|
|
|
Let me be more specific, the manual says
Quote: |
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. |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
|
|
Show the damned JCL and talk with the JES2 people if there is a JES2 exit implemented that uses the jobcard info to change the dsname. |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
pahiker wrote: |
Let me be more specific, the manual says
Quote: |
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.
Quote: |
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.
DEFINE CLUSTER(NAME('SYS1.MACLIB') ... |
|
Back to top |
|
|
pahiker
New User
Joined: 10 Aug 2012 Posts: 51 Location: USA
|
|
|
|
steve-myers wrote: |
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.
DEFINE CLUSTER(NAME('SYS1.MACLIB') ... |
Let me try that, what I had read, maybe I misread, stated that you could not use quotes on the allocate. I'll get back, thanks. |
|
Back to top |
|
|
pahiker
New User
Joined: 10 Aug 2012 Posts: 51 Location: USA
|
|
|
|
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. |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
pahiker wrote: |
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. |
|
Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009 Posts: 580 Location: London
|
|
|
|
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. |
|
Back to top |
|
|
|