Can the userid.SPFTEMPn.CNTL DSN be customized?
Farley, Peter x23353
If a SUBMIT is done from the old LPAR and then another SUBMIT is tried from the new LPAR, the programmer gets a "DATASET IN USE" error on the new LPAR for the userid.SPFTEMP0.CNTL dataset (I presume this dataset is created by SUBMIT, right?). Here are the error messages with names masked:
ISPF system data set allocation error - press Enter to continue.
Temporary control card data set cannot be allocated.
Data set 'XXXXXXX.SPFTEMP0.CNTL' in use by another user, try later.
MIM1038I XXXXXXX contention with XXXXXXX OWNS EXCL on ZZZZ CN(INTERNAL)
MIM1039I XXXXXXX needs EXCL SYSDSN XXXXXXX.SPFTEMP0.CNTL CN(INTERNAL)
Can the userid.SPFTEMPn.CNTL dataset name be customized to include the LPAR name to avoid this problem? E.G., can I specify the temp name somewhere as userid.LPARNAME.SPFTEMPn.CNTL? If so, where would that customization be done?
I'm not the sysprog on this, just one of the developers piloting the new LPAR and reporting issues, so please be gentle.
TIA for any info, RTFM pointers, or help you can provide.
Peter
--
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
Binyamin Dissen
<Peter....@BROADRIDGE.COM> wrote:
:>We're implementing a small development-only LPAR and allowing simultaneous logons to the current dev LPAR and the new one. The new LPAR uses a different SPFPROF library DSN to avoid PDS sharing problems on the profile dataset.
:>If a SUBMIT is done from the old LPAR and then another SUBMIT is tried from the new LPAR, the programmer gets a "DATASET IN USE" error on the new LPAR for the userid.SPFTEMP0.CNTL dataset (I presume this dataset is created by SUBMIT, right?). Here are the error messages with names masked:
:>ISPF system data set allocation error - press Enter to continue.
:>Temporary control card data set cannot be allocated.
:>Data set 'XXXXXXX.SPFTEMP0.CNTL' in use by another user, try later.
:>MIM1038I XXXXXXX contention with XXXXXXX OWNS EXCL on ZZZZ CN(INTERNAL)
:>MIM1039I XXXXXXX needs EXCL SYSDSN XXXXXXX.SPFTEMP0.CNTL CN(INTERNAL)
:>Can the userid.SPFTEMPn.CNTL dataset name be customized to include the LPAR name to avoid this problem? E.G., can I specify the temp name somewhere as userid.LPARNAME.SPFTEMPn.CNTL? If so, where would that customization be done?
:>I'm not the sysprog on this, just one of the developers piloting the new LPAR and reporting issues, so please be gentle.
:>TIA for any info, RTFM pointers, or help you can provide.
ISPF exit 16
--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
Farley, Peter x23353
> From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On Behalf Of
> Binyamin Dissen
> Sent: Wednesday, November 24, 2010 4:55 PM
> To: ISP...@LISTSERV.ND.EDU
> Subject: Re: Can the userid.SPFTEMPn.CNTL DSN be customized?
>
> On Wed, 24 Nov 2010 16:46:52 -0500 "Farley, Peter x23353"
> <Peter....@BROADRIDGE.COM> wrote:
> :> LPAR and reporting issues, so please be gentle.
> :>
> :>TIA for any info, RTFM pointers, or help you can provide.
>
> ISPF exit 16
Thank you, I'll pass that on to our sysprogs.
Don Leahy
Lizette Koehler
feature called Sharing ISPF User Ids.
This might be something to investigate.
Otherwise the ISPF Configuration Dialog can do this for you. Our temp files
for ISPF are called USERID.SYSNAME.??
Lizette
Farley, Peter x23353
> From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On Behalf Of
> Lizette Koehler
> Sent: Wednesday, November 24, 2010 5:37 PM
> To: ISP...@LISTSERV.ND.EDU
> Subject: Re: Can the userid.SPFTEMPn.CNTL DSN be customized?
>
> feature called Sharing ISPF User Ids.
>
> This might be something to investigate.
>
> Otherwise the ISPF Configuration Dialog can do this for you. Our temp
> files for ISPF are called USERID.SYSNAME.??
Only V1.10 here, so that isn't an option yet. I will pass the configuration info to my sysprogs, thanks.
Ted MacNEIL
Actually by ISPF.
I think the answer is yes, but it's been a long time since I've done any ISPF work.
There is a customisation/installation guide available on the IBM web site.
-
Ted MacNEIL
eama...@yahoo.ca
Mark Zelden
1) ISPF exit 16 will work, but you haven't needed it for over 10 releases
for this purpose (since OS/390 R10). There is an option in the
configuration table as already mentioned. The keyword is
ISPF_TEMPORARY_DATA_SET_QUALIFIER=
2) Profile sharing is available starting at z/OS 1.9, so the OP can use it.
However, I don't think it buys you much (search the archives for past
discussions).
Although trying to use a single userid on multiple sharing systems is not
the question or issue here, the documentation on my web site and
CBT file 434 covers the above items and there is also sample exit 16
source code. The URL to my web site is below in my signature. Look
for $SNGLTSO.TXT in the JOBs/DOC section of the site.
Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:mze...@flash.net
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
Paul Gilmartin
>> (I presume this dataset is created by SUBMIT, right?).
>
> Actually by ISPF.
>
Ah! Then in either case, can it be bypassed by avoiding
SUBMIT and writing directly to W(INTRDR)?
-- gil
Mark Zelden
Yes, but no need. Since it is an ISPF issue, just plain 'ol TSO
SUBMIT 'DATA.SET' avoids the use.
I haven't run into it in a long time, but I used TSO SUBMIT more often
in "the old days" when submitting vary large jobs - for example, the
NCP Stage 2 generation. These days, most shops allocate the temp ISPF
data sets big enough. I actually have been freeing / re-allocate them to VIO
in my own logon process for many years going back to when I first started
consulting and ran into problems at different shops.
Paul Gilmartin
>>>
>> Ah! Then in either case, can it be bypassed by avoiding
>> SUBMIT and writing directly to W(INTRDR)?
>
> Yes, but no need. Since it is an ISPF issue, just plain 'ol TSO
> SUBMIT 'DATA.SET' avoids the use.
>
> I haven't run into it in a long time, but I used TSO SUBMIT more often
> in "the old days" when submitting vary large jobs - for example, the
> NCP Stage 2 generation. These days, most shops allocate the temp ISPF
> data sets big enough. I actually have been freeing / re-allocate them to VIO
> in my own logon process for many years going back to when I first started
> consulting and ran into problems at different shops.
>
any use of temp files, and also submitting with the attributes of
the file being edited, rather than forcing F80.
-- gil
Farley, Peter x23353
> From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On
> Behalf Of John McKown
> Sent: Wednesday, November 24, 2010 6:37 PM
> To: ISP...@LISTSERV.ND.EDU
> Subject: Re: Can the userid.SPFTEMPn.CNTL DSN be customized?
>
> short. The DSN ends up being prefixed with
> &userid..SYS&sysname.<rest of the dsn>
Thanks John. Much appreciated.
Farley, Peter x23353
> From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On
> Behalf Of Mark Zelden
> Sent: Thursday, November 25, 2010 10:24 AM
> To: ISP...@LISTSERV.ND.EDU
> Subject: Re: Can the userid.SPFTEMPn.CNTL DSN be customized?
>
>
> 1) ISPF exit 16 will work, but you haven't needed it for over
> 10 releases for this purpose (since OS/390 R10). There is an
> option in the configuration table as already mentioned. The
> keyword is ISPF_TEMPORARY_DATA_SET_QUALIFIER=
>
> 2) Profile sharing is available starting at z/OS 1.9, so the
> OP can use it. However, I don't think it buys you much (search
> the archives for past discussions).
>
> Although trying to use a single userid on multiple sharing
> systems is not the question or issue here, the documentation on
> my web site and CBT file 434 covers the above items and there
> is also sample exit 16 source code. The URL to my web site is
> below in my signature. Look for $SNGLTSO.TXT in the JOBs/DOC
> section of the site.
Thanks Mark. I will point my sysprogs to that info and check the
archives about profile sharing.
Paul Gilmartin
>>>
>>>
>> Ah! Then in either case, can it be bypassed by avoiding
>> SUBMIT and writing directly to W(INTRDR)?
>
> Yes, but no need. Since it is an ISPF issue, just plain 'ol TSO
> SUBMIT 'DATA.SET' avoids the use.
>
Edit/View/Browse. My habit is to make minor adjustments in
View; SUBmit; then CANcel. (If necessary, I can later view
the JCL as edited with SDSF SJ.)
-- gil
McKown, John
/* REXX */
ADDRESS ISREDIT
"MACRO"
"(MAXLINE) = LINENUM .ZL"
LINE.0=MAXLINE
DO LINENO=1 TO MAXLINE
"(RECORD) = LINE "LINENO
LINE.LINENO=RECORD
END
"(LRECL)=LRECL"
"(FV,JUNK)=RECFM"
FV=FV' B'
ADDRESS TSO
"ALLOC DDN(INTRDR) SYSOUT(*) WRITER(INTRDR) REUSE "||,
"LRECL("LRECL") RECFM("FV")"
"EXECIO DISKW INTRDR(STEM LINE. FINIS"
"FREE DDN(INTRDR)"
The above is not tested.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
> -----Original Message-----
> From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, November 26, 2010 10:57 AM
> To: ISP...@LISTSERV.ND.EDU
> Subject: Re: Can the userid.SPFTEMPn.CNTL DSN be customized?
>
Ted MacNEIL
It's not ISPF EDIT SUBMIT's insistance, rather its catering to TSO SUBMIT's insistance.
Try just doing a 'raw' submit with an non FB80 file.
ISPF EDIT is just getting around an inherent restriction of TSO.
-
Ted MacNEIL
eama...@yahoo.ca
Paul Gilmartin
>> This also could be use to get around ISPF EDIT SUBMIT's insistance of RECFM=FB / LRECL=80.
>
> It's not ISPF EDIT SUBMIT's insistance, rather its catering to TSO SUBMIT's insistance.
>
OK. It's ISPF's insistence on catering to TSO.
> Try just doing a 'raw' submit with an non FB80 file.
>
Not lately. Has anything changed?
> ISPF EDIT is just getting around an inherent restriction of TSO.
>
I don't call that "getting around", I call that "surrendering to".
I suppose ISPF might use TSO's antiquated rigidity as an excuse;
what's TSO's excuse? But if TSO relaxed the restriction, would
ISPF be likely to follow? Astonishingly, it's JCL/Job Processing
which long ago for JES3, relatively recently for JES2, relaxed the
restriction.
-- gil
McKown, John
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
> -----Original Message-----
> From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, November 26, 2010 4:11 PM
> To: ISP...@LISTSERV.ND.EDU
> Subject: Re: Can the userid.SPFTEMPn.CNTL DSN be customized?
>
Ted MacNEIL
>>
>OK. It's ISPF's insistence on catering to TSO.
What would you rather have?
SUBMIT fail?
>> Try just doing a 'raw' submit with an non FB80 file.
>
>Not lately. Has anything changed?
No, and that was my point.
>> ISPF EDIT is just getting around an inherent restriction of TSO.
>>
>I don't call that "getting around", I call that "surrendering to".
Again, would you rather have the SUBMIT fail?
TSO SUBMIT has a restriction.
ISPF has a workaround.
Is it ISPF's fault?
>I suppose ISPF might use TSO's antiquated rigidity as an excuse; what's TSO's excuse?
Is it an excuse?
ISPF is solving a problem, that is not its problem.
>But if TSO relaxed the restriction, would ISPF be likely to follow?
Who knows?
ISPF just addressed a 'simple' issue.
If TSO is 'fixed' maybe ISPF will be as well.
>Astonishingly, it's JCL/Job Processing which long ago for JES3, relatively recently for JES2, relaxed the restriction.
Yah? So? It's the TSO SUBMIT command which has the restriction.
Rather than create a new SUBMIT, ISPF just used an existing interface, rightly or wrongly, so until it's 'fixed' ISPF is doing the right thing.
-
Ted MacNEIL
eama...@yahoo.ca
Paul Gilmartin
>>> It's not ISPF EDIT SUBMIT's insistance, rather its catering to TSO SUBMIT's insistance.
>>>
>
>> OK. It's ISPF's insistence on catering to TSO.
>
> What would you rather have?
> SUBMIT fail?
>
Certainly. That would clearly display the onus where it
belongs.
>>> ISPF EDIT is just getting around an inherent restriction of TSO.
>>>
>> I don't call that "getting around", I call that "surrendering to".
>
> Again, would you rather have the SUBMIT fail?
> TSO SUBMIT has a restriction.
> ISPF has a workaround.
>
It's not a "workaround"; it produces incorrect results.
> Is it ISPF's fault?
>
Yes, insofar as ISPF is relying on an inadequate interface.
>> I suppose ISPF might use TSO's antiquated rigidity as an excuse; what's TSO's excuse?
>
> Is it an excuse?
> ISPF is solving a problem, that is not its problem.
>
Can you explain to me why you consider quietly (not even a warning
message) truncating the programmer's data "solving a problem"?
> Yah? So? It's the TSO SUBMIT command which has the restriction.
>
> Rather than create a new SUBMIT, ISPF just used an existing interface, rightly or wrongly, so until it's 'fixed' ISPF is doing the right thing.
>
Wrongly.
-- gil
Ted MacNEIL
>
>Certainly. That would clearly display the onus where it
belongs.
Well, we obviously disagree.
I'd rather have it succeed than have annoyed users.
Or, have to retrain them.
-
Ted MacNEIL
eama...@yahoo.ca
Paul Gilmartin
>>> What would you rather have? SUBMIT fail?
>>
>> Certainly. That would clearly display the onus where it
> belongs.
>
> Well, we obviously disagree.
> I'd rather have it succeed than have annoyed users.
> Or, have to retrain them.
>
It doesn't succeed, and I'm an annoyed user. You'd lose on
either count if I were your user. It seems you'd rather
have it fail for some users than have others annoyed.
-- gil
Ted MacNEIL
Why doesn't it succeed?
>You'd lose on either count if I were your user.
I've never had a truncation issue.
I was taught, over 30 years ago, to NEVER make JCL over 80 bytes.
>It seems you'd rather
have it fail for some users than have others annoyed.
Are you deliberately trying to break SUBMIT, or are you trying to do your job?
SUBMIT, and other TSO commands, have issues.
But, I would rather things work, work within the restrictions getting the job done, rather than b*tching and pointing out all the failures/restrictions.
It may not be pretty, but the bottom line is the job is done.
Go ahead and break SUBMIT; the rest of us will continue to deliver our deliverables.
-
Ted MacNEIL
eama...@yahoo.ca
Paul Gilmartin
>> It doesn't succeed, and I'm an annoyed user.
>
> Why doesn't it succeed?
>
Truncation.
>> You'd lose on either count if I were your user.
>
> I've never had a truncation issue.
> I was taught, over 30 years ago, to NEVER make JCL over 80 bytes.
>
Thirty years ago would have been 1980. This is 2010, or hadn't
you noticed?
Over 30 years ago, you were likely similarly taught to NEVER make
REGION over 16M. Do you, nowadays, equally mindlessly follow that
equally outdated precept. You could probably do your job within
16M, breaking your programs into multiple job steps, and using
overlays, but why adhere to pernicious tradition?
>> It seems you'd rather
> have it fail for some users than have others annoyed.
>
> Are you deliberately trying to break SUBMIT, or are you trying to do your job?
>
Trying to do my job. A couple years ago, I was coding a Rexx EXEC
to read data from SYSIN and process it as part of my job. I
considered that the data might exceed 80 bytes, and was struggling
to invent a continuation convention, and an implementation in the
EXEC, and a programmed technique to transform the data to that
format. Then I had a flash of insight: "I needn't think like
[Ted MacNEIL]; I can simply use longer lines in SYSIN." Works
great; it was liberating! Of course, I can't use SUBmit. But I
have other techniques. But why should every programmer be required
to invent circumventions when SUBMIT could be fixed once and for
all.
> Go ahead and break SUBMIT; the rest of us will continue to deliver our deliverables.
>
I needn't break SUBMIT. IBM has done that task for me.
-- gil
McKown, John
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
> -----Original Message-----
> From: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Sunday, November 28, 2010 10:08 AM
> To: ISP...@LISTSERV.ND.EDU
> Subject: Re: Can the userid.SPFTEMPn.CNTL DSN be customized?
>
Rob Zenuk
because he disagrees with a documented restriction. Why not simply use a
dataset as input with an LRECL > 80? Let's keep IBM and this list focused
on the important stuff not silly little stuff like this where there are
completely acceptable "workarounds" that actually make more sense, are more
maintainable and user friendly. Let's share generally accepted successful
approaches rather than bash IBM and other members of the list for some very
insignificant limitations that all of us have learned to painlessly live
with.
Rob
In a message dated 11/28/2010 9:08:19 A.M. US Mountain Standard Time,
John McKown
characters. TSO SUBMIT, and so ISPF, cannot do this. It's a restriction
that most z/OS users are simply not usually aware of. However, I'm fairly
sure that Gil comes from a UNIX background and so is not used to it.
Especially newer users who weren't raised on 80 character terminals.
Just my ongoing weird opinions. Worth talking about, maybe, but not worth
getting upset about. But I don't know how much of my reaction are due to my
meds. And I am on some that I'm not used to.
--
John McKown
Maranatha! <><
Sent from my Vibrant Android phone.
Höglund Lars
-----Ursprungligt meddelande-----
Från: ISPF discussion list [mailto:ISP...@LISTSERV.ND.EDU] För McKown, John
Skickat: den 26 november 2010 18:26
Till: ISP...@LISTSERV.ND.EDU
Ämne: Re: Can the userid.SPFTEMPn.CNTL DSN be customized?
Kenneth Klein
sysplex without conflicts.
//*----------------------------------------------------------------*/
//* TEMP DATASETS USED ONLY BY THE SUBMIT COMMAND 12/2010 KEK
//*----------------------------------------------------------------*/
//ISPCTL0 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)),
// DCB=(LRECL=80,BLKSIZE=800,RECFM=FB)
//ISPCTL1 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)),
// DCB=(LRECL=80,BLKSIZE=800,RECFM=FB)
//*----------------------------------------------------------------*/
Kenneth Klein
Systems Specialist
502-868-3644
859-750-5179 (Cell)
502-868-2298 (Fax)
kennet...@tema.toyota.com
Höglund Lars <Lars.H...@ALECTA.SE>
Sent by: ISPF discussion list <ISP...@LISTSERV.ND.EDU>
11/30/2010 03:34 AM
Please respond to
ISPF discussion list <ISP...@LISTSERV.ND.EDU>
Subject
SV: Can the userid.SPFTEMPn.CNTL DSN be customized?
Mark Zelden
<kennet...@TEMA.TOYOTA.COM> wrote:
>We put this in the tso logon proc so you can submit from any lpar in the
>sysplex without conflicts.
>
>//*----------------------------------------------------------------*/
>//* TEMP DATASETS USED ONLY BY THE SUBMIT COMMAND 12/2010 KEK
>//*----------------------------------------------------------------*/
>//ISPCTL0 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)),
>// DCB=(LRECL=80,BLKSIZE=800,RECFM=FB)
>//ISPCTL1 DD DISP=NEW,UNIT=VIO,SPACE=(CYL,(1,1)),
>// DCB=(LRECL=80,BLKSIZE=800,RECFM=FB)
>//*----------------------------------------------------------------*/
>
Just a note: AFAIK, only ISPCTL0 is used for SUBMIT (and edit) but
ISPCTL1-n is used for ISPF file tailoring (one needed for each
logical screen up to max number of split screens allowed as
specified in the config). I also allocate these files to VIO, but
specify ISPCTL1-4.