Caveat: insert the daily digesting delay here...
Lizette: I concur with Graham; isn't &DSN(4) for a temp dataset (at most
generic sites) the same as &DDNAME? In addition, your code will change *all*
temp datasets with MYUSER1 DD name. You might want to provide some other
limiting factor unless it is truly for *all* users. [1] As Greg Shirey
mentioned, DataClas & values (many) can be over-ridden in JCL or DynAlloc. I
have the little snippet below to bypass the auto-assignment when a class name
has been supplied.
DataClas ACS snippet:
/* Step 1: convert special/virtual/obsolete values */
…
/* Step 2: a selection has been made or provided */
IF &DATACLAS NE '' THEN DO
EXIT
END
/* Step 3: make a choice when no value specified */
SELECT …
In fact, I'll go out on a limb and suspect you're trying to accommodate the
work-around for C/C++ IPA Link and temp PDSE datasets. [2] Below is the
DataClas ACS workaround that I've adapted from the IBM webpage suggestion. [3]
DataClas ACS snippet:
/* IPALINK Note: Bypass CCN* Programs */
FILTLIST CCPGM INCLUDE(CCN*)
- - - - - - - - - - - - - - - 111 Line(s
/* 2015.02.09 IGDSMS10 - C/C++ IPA conflict - bgn */
WHEN (&PGM EQ &CCPGM
AND &DSNTYPE EQ 'LIBRARY') DO
/* Bypass CCN* C/C++ Programs */
/* Example: CCNDRVR */
WRITE 'DataClas(' &DATACLAS ') set to CCN@PDSE '
'for program(' &PGM ')'
WRITE
' Env:' &ACSENVIR +
', XMode:' &XMODE +
', DsType:' &DSTYPE +
', DsnType:' &DSNTYPE +
', DsOrg:' &DSORG +
', NVol:' &NVOL +
', SpaceType:' &SPACE_TYPE +
', MaxSz:' &MAXSIZE +
', Size:' &SIZE
SET &DATACLAS = 'CCN@PDSE'
END
/* 2015.02.09 IGDSMS10 - C/C++ IPA conflict - end */
ISMF snippet:
DATACLAS AVG SPACE SPACE VOLUME DYNVOL
NAME AVGREC VALUE PRIMARY SECONDARY COUNT COUNT
--(2)--- -(8)-- -(9)- -(10)-- --(11)--- -(14)- -(16)-
CCN@PDSE M 1 50 50 --- --
SMALL M 1 50 50 --- 10
The only difference between the specialized CCN@PDSE data class [4] and the
normal one that would have been auto-assigned is the DynVol Count value. The
compiler can't deal with the fact that, when Vol Count is not specified in the
DataClas, it defaults to one (1) & DynVol Count only comes into play when the
dataset attempts to extend beyond the initial volume’s capacity ie. an x37
scenario. The problem that the compiler doesn't comprehend is the PDSE
routines themselves will cause a failure before DynVol Count is even
contemplated. In fact, I have many PDSE libraries whose Data Class specifies a
DynVol Count and no problems reported. [5]
[1] perhaps you’re trying to do something for sorting? The examples from the
IBM manual (DFSort or DFSMS? can’t remember) suggest using &DDNAME to
distinguish.
[2] the 'new' C/C++ (ours came with z/OS v2.1) compiler fails when doing
IPALINK & allocating the temporary PDSE libraries having a DataClas with
DynVolCount specified. IPA Link creates Program Objects which, in turn,
require a PDSE library for storage.
[3] You can leave out the diagnostic WRITE, of course. There is only one
person here (the senior SysProg) that dabbles in C programming so he can
provide the information to IBM as they work on the PMR.
[4] The web page wanted no class to be assigned but I didn’t feel that was a
valid response. Instead, I gave the senior SysProg his own class that can be
altered as the PMR requires. Once they’ve fixed their problem, we can go back
to the generic classes already in use.
[5] Data classes have been auto-assigned for all SMS datasets for more than
two (2) years and they all have a DynVol Count >10 to avoid x37 problems.
--------> signature = 6 lines follows <--------
Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585 fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee
“How *do* you plan for something like that?” Guardian Bob, Reboot
“For every action, there is an equal and opposite criticism.”
“Systems Programming: Guilty, until proven innocent” John Norgauer 2004
-----Original Message-----
From: Graham Harris [mailto:har…@GMA...COM]
Sent: March 17, 2015 15:37
Subject: Re: SMS ACS and TEMP DSN Parsing
Would checking the DDNAME and/or PROGRAM help?
On 17 March 2015 at 15:10, Vernooij, CP (ITOPT1) - KLM <
[email protected]<mailto:[email protected]>> wrote:
> Well, the temp-dsn pattern will probably only change with z/OS
> releases, so it will (only) be another item on that checklist.
>
> -----Original Message-----
> From: IBM Mainframe Discussion List
> On Behalf Of Lizette Koehler
> Sent: Tuesday, March 17, 2015 3:34 PM
> Subject: Re: SMS ACS and TEMP DSN Parsing
>
> Yes, that I understand. However, I have always been reluctant to set
> any TEMP DSN different than other TEMP DSNs. But this is a unique
> case and I am hoping this will resolve the issue.
>
> The other issue is the consistency for the temp DSN pattern. If
> anything changes, this code will no longer work. (Sigh)
>
> > -----Original Message-----
> > From: IBM Mainframe Discussion List
> > On Behalf Of Greg Shirey
> > Sent: Tuesday, March 17, 2015 7:30 AM
> > Subject: Re: SMS ACS and TEMP DSN Parsing
> >
> > I don't think there's anything wrong with the logic, but you know
> > that most
> > attributes of a DATACLAS can be overridden.
> >
> > -----Original Message-----
> > From: IBM Mainframe Discussion List
> > On Behalf Of Lizette Koehler
> > Sent: Monday, March 16, 2015 7:02 PM
> > Subject: SMS ACS and TEMP DSN Parsing
> >
> > I am trying to create a process in the Dataclas that will change
> > some of the
> > dataset attributes of on specific Temp DSN.
> >
> > The DSN comes in with DSTYPE = TEMP
> >
> > Does anyone know if this will work? The DSN will look like this:
> > SYS15070.T105514.RA000.MYDSN1.R0226931
> >
> > If (&DSTYPE = Temp and &DSN(4) = 'MYDSN1')
> > Then Do
> > Set Dataclas = X
> > Write DSN set to X Dataclas
> > Exit
> > End
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
