Re: TSO temp dataset

Ron Hawkins wrote: >We're talking about the temp dataset that ISPF==>EDIT==>SUB command creates >before copying to INTRDR. Correct, but actually, in this specific thread, it is about how the allocation is done by zSecure and how to fix it. zSecure has its own version of Submit running REXX

Re: TSO temp dataset

We're talking about the temp dataset that ISPF==>EDIT==>SUB command creates before copying to INTRDR. I think you're talking about the temp data sets in the submitted JCL. Not the same thing. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]

Re: TSO temp dataset

Not sure whether I fully understand the problem here, but anyways.   You can override the number of extents that can be allocated to your temp dataset(s) by specifying the maximum number of volsers to use - in which case *each* volume will be allocated up to 16 extents, e.g.   

Re: TSO temp dataset

On Thu, Feb 15, 2018 at 8:01 AM, Nai, Dean wrote: > When you submit a job through TSO your temp dataset gets created. I'm > trying to submit a big job and my temp dataset keeps on running out of > space. Any way of increasing the size of itthanks > > > Dean Nai > Senior

Re: J line command was: TSO temp dataset

On 2/15/2018 8:43 PM, Charles Mills wrote: How is ISPF packed data compressed? Is it simple run length encoding? Couldn't some clever soul write some sort of generalized un-PACK command or utility program that could somehow front-end other commands? Use pipes or a behind-the-scenes temporary

Re: J line command was: TSO temp dataset

How is ISPF packed data compressed? Is it simple run length encoding? Couldn't some clever soul write some sort of generalized un-PACK command or utility program that could somehow front-end other commands? Use pipes or a behind-the-scenes temporary dataset or ... ? Yeah, I know, wrong place

Re: Best Practices for z/OS Maintenance

We also use the RESVOL as the base mount point, but then mount ALL of the filesystems starting with the SMPE serviced ROOT, and everything else. Then you have the entire tree available for SMPE maintenance. _ Dave Jousma Manager

Re: Parmlib members change control?

Years ago, I had the opportunity to work with NewEra's ImageFocus. Neat stuff to perform "virtual IPLs" (my description, not theirs), running the gauntlet based on loadparm and load address, checking syntax of members, verifying existence of data sets, etc.Like I say, neat stuff. Anyway, they were

Re: J line command was: TSO temp dataset

On Fri, 16 Feb 2018 00:32:53 +, Jesse 1 Robinson wrote: >Nice catch! I never considered the effect of PACK. The reason why ISPF >allocates and copies to a separate data set is that the JCL on the screen does >not necessarily match the current physical content on disk. The JCL may not >have

Re: WLM and response time

I'm wondering if state sampling for these non ending transactions are part of the overall emphasis on the performance of the service class. If these samples were discarded for non ending, high resource usage transactions as an example, I could envision some unfavorable results to service

Re: J line command was: TSO temp dataset

Nice catch! I never considered the effect of PACK. The reason why ISPF allocates and copies to a separate data set is that the JCL on the screen does not necessarily match the current physical content on disk. The JCL may not have been saved yet (or ever), or !aha! it may be PACKed on disk. TSO

Re: J line command was: TSO temp dataset

On Thu, 15 Feb 2018 16:27:35 -0700, Sri h Kolusu wrote: > >Check if you have PACK ON in your Profile. > >I can replicate your JCL error if the member has PACK ON and I get a JCL >error. > >TYPE PACK OFF while editing the member and save it then try the J command > PACK is a recurrent source of

Re: J line command was: TSO temp dataset

On Thu, 15 Feb 2018 14:35:52 -0700, Sri h Kolusu wrote: > >You need to look in ISPF User's guide Vol 1 under the section "Library and >data set list utility line commands" > >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54ug00/bdpr.htm > RCF submitted. It's

Re: J line command was: TSO temp dataset

Pommier Rex, Check if you have PACK ON in your Profile. I can replicate your JCL error if the member has PACK ON and I get a JCL error. TYPE PACK OFF while editing the member and save it then try the J command Thanks, Kolusu IBM Mainframe Discussion List wrote on

Re: J line command was: TSO temp dataset

I don't ever remember using J line command before now, but it seems to work exactly right for me. It looks as if J is not recognizing your job card and cooking one up on the fly. What happens if you enter SUBMIT as a TSO command against the same member? . . J.O.Skip Robinson Southern

J line command was: TSO temp dataset

Subject change due to topic drift. I don't know what I'm doing wrong. z/OS 2.2. My PDS member looks like this: EDIT RRP.JCL(I) - 01.04 Columns Command ===>

Re: DASD problem

John has attached numbers to my previous opinion: synchronous PPRC is not a good choice for continuous mirroring over any significant distance. You may be able to tweak some option here or there, but it's a game of whack-a-mole: today's manageable problem will morph into yet another problem

Re: TSO temp dataset

>>Am I looking in the wrong place? Gil, You need to look in ISPF User's guide Vol 1 under the section "Library and data set list utility line commands" https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.f54ug00/bdpr.htm Thanks, Kolusu IBM Mainframe Discussion List

Re: TSO temp dataset

It's at: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.f54ug00/bdpr.htm?view=kc In article <1392861559270957.wa.paulgboulderaim@listserv.ua.edu> you wrote: > On Thu, 15 Feb 2018 20:33:57 +, PINION, RICHARD W. wrote: > >J works from ISPF member list. Might

Re: TSO temp dataset

I prefer to read up on what's new before the install. It saves time in the long run. YMMV. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of PINION, RICHARD W.

Re: TSO temp dataset

After installing a new release of z/OS, and I'm bored and have nothing better to do, I go through the ISPF help panels to see what's new. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, February 15,

Re: TSO temp dataset

On 2018-02-15 15:33, PINION, RICHARD W. wrote: J works from ISPF member list. Might even work for sequential data sets from ISPF 3.4. I stand [partially] corrected. Line command J is recognized and performs a submit in a ISPF 3.1 member list. Line command J is recognized and performs a

Re: TSO temp dataset

On Thu, 15 Feb 2018 20:33:57 +, PINION, RICHARD W. wrote: >J works from ISPF member list. Might even work for sequential data sets from >ISPF 3.4. > In: z/OS IBM ISPF User's Guide Volume II Version 2 Release 3 SC19-3628-30 Chapter 5. Utilities (option 3) Data set list utility

Re: TSO temp dataset

There's no reason why TSO would have head of an ISPF line command. It don't know whether ISPF has heard of it; it could be a local line command at Yitzchak's installation. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe

Re: TSO temp dataset

Or from any panel command line: TSO SUB 'dataset(member)' On Thu, 15 Feb 2018 12:32:48 -0700, Lizette Koehler wrote: >So the problem is the ISPF Temp files not TSO. You can use option 3.4 and >type SUB next to the member to submit and avoid the temp datasets >

Re: TSO temp dataset

J works from ISPF member list. Might even work for sequential data sets from ISPF 3.4. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Thursday, February 15, 2018 3:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re:

Re: TSO temp dataset

On Thu, 15 Feb 2018 21:51:27 +0200, Itschak Mugzach wrote: >If you copy the jcl to another PDS you can use the “j” (submit) command which >does not use temporary dataset for job submission. Never tested myself, but it >probably works with sequential datasets as well. > Y'know, this recurrently

Re: TSO temp dataset

On 2018-02-15 14:51, Itschak Mugzach wrote: If you copy the jcl to another PDS you can use the “j” (submit) command which does not use temporary dataset for job submission. Never tested myself, but it probably works with sequential datasets as well. I've never heard of this. IKJ56500I

Re: CKD #2 - KEY

Okay, the answer is that those tables give capacities for specific ranges of key sizes and for specific ranges of data sizes. So, yes, they do take the key size into account. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe

Re: TSO temp dataset

If you copy the jcl to another PDS you can use the “j” (submit) command which does not use temporary dataset for job submission. Never tested myself, but it probably works with sequential datasets as well. ITschak נשלח מה-iPad שלי ‫ב-15 בפבר׳ 2018, בשעה 21:32, ‏‏Lizette Koehler

Re: CKD #2 - KEY

W dniu 2018-02-15 o 17:52, Seymour J Metz pisze: What are the column headers for that table? Is there a table with a column labeled KL+DL? Kl=range DL Bytes (Max)? The column is named "Percent Space Used".

Re: TSO temp dataset

So the problem is the ISPF Temp files not TSO. You can use option 3.4 and type SUB next to the member to submit and avoid the temp datasets Or you can have your storage admin check to see if they have any restrictions on size allocation of ISPF Temp datasets. Or you could go to OPTION 6 in

Re: TSO temp dataset

We use z/Secure and I generally generate the commands and after PF3, you have the option to edit the generated commands. At this point I use the ISPF command CUT ALL. After that I PF3 out of the z/Secure panels. I have a separate JCL member that is used to submit z/Secure commands to run in

Re: WLM and response time

Here's an example of why I'm questioning this. This is from a book by Robert Vaupel. I know he's knowledgeable, but the explanation is confusing. Using an average response time example he says "The running or in-flight transactions are also captured in order to make sure that long running and

Re: WLM and response time

IIRC, WLM only uses ended transactions for the policy adjustment cycle. Further suggested reading SYSTEM Programmers Guide to WLM: www.redbooks.ibm.com/redbooks/pdfs/sg246472.pdf -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of

Re: Parmlib members change control?

On 2018-02-15 09:21, Ira Nelson wrote: We used a product called Eventaction, formerly Changeaction. We used it for additional controls on parmlib and other libraries. It produces some nice reports which our management loved. For anyone interested, information on eventACTION is available at

Re: Coding the equivalent of a Binder EXPAND

EXPAND doesn't rewriter it in place. This is in the category of things that I'd like to see tried somewhere where I won't be affected when (not if) the balloon goes up. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe

Re: TSO temp dataset

If zSECURE submits the job then it's a zSECURE issue, not a TSO issue. You may need to contact vendor support if there's nothing in the manual. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List

Re: WLM and response time

I agree. But the question remains. How does WLM manage a response time that is longer than the policy adjustment interval? Is it only based on ended transactions at that time (which would seem logical). I've also seen a lot of recommendations from various sources talking about short batch,

Re: TSO temp dataset

Using zSECURE to create the control cards. Editing them down and then zSECURE needs to submit the job. Dean Nai Senior z/OS Systems Programmer Mainframe Technical Support Group On 2/15/18, 11:23 AM, "IBM Mainframe Discussion List on behalf of Seymour J Metz"

Re: TSO temp dataset

I'm guessing the OP is referring to ISPCTLx data sets. You can preallocate these to larger datasets in your logon PROC. You may be able to preallocate them with REXX or CLIST before you run zSECURE command(s). I have not tried this. Ron -Original Message- From: IBM Mainframe

Re: Coding the equivalent of a Binder EXPAND

On Thu, 15 Feb 2018 16:54:22 +, Seymour J Metz wrote: >You can't do it with EXCP either. Of course, if you're willing to give up >"(safely)" ... > If the member is in use it's unliklely to be safe. If the member is not in use, re-link it with the EXPAND. In fact, neither PDS nor PDSE will

Re: Coding the equivalent of a Binder EXPAND

You can't do it with EXCP either. Of course, if you're willing to give up "(safely)" ... -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Binyamin Dissen

Re: CKD #2 - KEY

What are the column headers for that table? Is there a table with a column labeled KL+DL? Kl=range DL Bytes (Max)? It should look something like the tables in Appendix A of

Re: Parmlib members change control?

It's a royal pain, but if you don't do it then the consequences are also a royal pain. I'd urge that backout plans and reviews be part of the process. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List

Re: TSO temp dataset

What do you mean by "through TSO"? SUBMIT from the READY prompt? ISPF? "E, none of the above"? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Nai, Dean

Re: Parmlib members change control?

Change control of some type is a "necessary evil" at every shop I have worked in. For example in my last shop SYS1.PARMLIB, PROCLIB, anything related to production was under RACF Audit control so everything was tracked. Also in terms of manual change control we always took backups manually

Re: Parmlib members change control?

On Thu, 15 Feb 2018 14:56:31 +, Jousma, David wrote: >Yea, I'm not a fan of that either, especially when things are going south, and >a PARMLIB change needs to be made quickly. I do like the idea of automatic >change tracking like Ira mentioned with various software vendors that do that.

Re: Parmlib members change control?

I should have added that our DEV and PROD versions of PARMLIB/PROCLIB are not directly updateable, however we are a TSS shop, so we have our "special" ID's that operate in bypass mode, but everything done with it is logged, and every use has to be manually followed up with the "what's, and

Re: Parmlib members change control?

On Feb 15, 2018, at 7:38 AM, Sean Gleann wrote: > > Git has also been suggested, and I'm > still looking at that. > > Does anyone else do anything like this, and if so, would you be prepared to > share your experiences, please? Yes, I use git. I wrote a program that

Re: TSO temp dataset

I'll look into this...thanks everyone. Dean Nai Senior z/OS Systems Programmer Mainframe Technical Support Group On 2/15/18, 9:54 AM, "IBM Mainframe Discussion List on behalf of Elardus Engelbrecht"

Re: TSO temp dataset

Or for this one submission, just copy the edited dataset to INTRDR with an IEBGENER job. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, February 15, 2018 6:47 AM To: IBM-MAIN@LISTSERV.UA.EDU

Re: TSO temp dataset

>Also check SCKRCLIB(CKRESUB) these line: >"SELECT CMD(ALLOC FI(CKRSUBMI) DA('"workdsn"') SPACE(1 1)", I forgot about another allocation statement. Search in that same member for this word C2RFSUB and look for "space(1 1)" to enlarge that. HTH! Groete / Greetings Elardus Engelbrecht

Re: Parmlib members change control?

Yea, I'm not a fan of that either, especially when things are going south, and a PARMLIB change needs to be made quickly. I do like the idea of automatic change tracking like Ira mentioned with various software vendors that do that. When they provide before/after images of the members in

Re: TSO temp dataset

Nai, Dean wrote: >The problem is it gets submitted by a RACF product called zSECURE so I have no >control over it. I just generate the commands it uses and then tell it to >submit a job. In that case, check in zSecure option SE.0 that 'TSO SUBMIT' is not used. Also check SCKRCLIB(CKRESUB)

Re: DASD problem

Disclaimer: I am not a performance expert, so take this with a large grain of salt. I agree with what Ron wrote: That synchronously replicated disk I/O write response times are longer than those for volumes that are not replicated is not surprising. For basic PPRC it will be higher to start

Re: TSO temp dataset [USAA Confidential]

On Thu, 15 Feb 2018 14:06:12 +, Usher, Darrold wrote: >... >USAA nonfidential > Does your employer know that you're posting information marked "confidential" to a publicly accessible forum? -- gil -- For IBM-MAIN

Re: TSO temp dataset

On Thu, 15 Feb 2018 14:01:48 +, Nai, Dean wrote: >When you submit a job through TSO your temp dataset gets created. I'm trying >to submit a big job and my temp dataset keeps on running out of space. Any way >of increasing the size of itthanks > I don't believe the TSO SUBMIT command

Re: TSO temp dataset

I'm assuming you SMS manage temporary datasets. If so, assign them to a data class with enough dasd space. Mark Jacobs Nai, Dean February 15, 2018 at 9:31 AM The problem is it gets submitted by a RACF product called zSECURE so I have no control over it. I just

Re: TSO temp dataset

The problem is it gets submitted by a RACF product called zSECURE so I have no control over it. I just generate the commands it uses and then tell it to submit a job. Dean Nai Senior z/OS Systems Programmer Mainframe Technical Support Group On 2/15/18, 9:01 AM, "IBM

Re: Parmlib members change control?

Sean Gleann wrote: >I'm coming under pressure from 'upstairs' regarding the idea of implementing >change control or versioning on parmlib members and other 'control'-type files >(WLM policy, SMS rules, RACF, etc) >Currently, I manually maintain 'change history' comments in each member, and a

Re: Parmlib members change control?

I have heard of some shops that had SYS1.PARMLIB under LIBRARIAN or PANVALET control. I (fortunately) have never had to work in any of them. HTH, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sean Gleann Sent: Thursday, February

Re: Parmlib members change control?

We used a product called Eventaction, formerly Changeaction. We used it for additional controls on parmlib and other libraries. It produces some nice reports which our management loved. Sent from my iPad > On Feb 15, 2018, at 8:38 AM, Sean Gleann wrote: > > I'm

Re: WLM and response time

Response time goals for batch do not (IMO) make any sense. WLM is predicated on having enough samples to make an informed decision. If you only have 1 or 2 samples (ended transactions) in an interval, that is not statistically valid. I would suggest a velocity goal be used in its place. If

Re: TSO temp dataset [USAA Confidential]

If you have it in a data set you do not have to go to ready. If it is a member bring up the member list and enter sub in the command column. If it is not a member, go to 3.4 and enter sub in the command column. Dennis Roach, CISSP AIG Identity & Access Management | Technology Services 2929

Re: Parmlib members change control?

We use endevor... I will be interested to know if someone is managing the parmlibs using GIT... On 15-Feb-2018 7:09 PM, "Sean Gleann" wrote: > I'm coming under pressure from 'upstairs' regarding the idea of > implementing change control or versioning on parmlib members

Re: TSO temp dataset [USAA Confidential]

A workaround is go to TSO READY and use the submit command. SUBMIT 'dataset(member)' as an example USAA Confidential -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nai, Dean Sent: Thursday, February 15, 2018 8:02 AM To:

TSO temp dataset

When you submit a job through TSO your temp dataset gets created. I'm trying to submit a big job and my temp dataset keeps on running out of space. Any way of increasing the size of itthanks Dean Nai Senior z/OS Systems Programmer Mainframe Technical Support Group >

Parmlib members change control?

I'm coming under pressure from 'upstairs' regarding the idea of implementing change control or versioning on parmlib members and other 'control'-type files (WLM policy, SMS rules, RACF, etc) Currently, I manually maintain 'change history' comments in each member, and a previous version 'backout'

Re: Coding the equivalent of a Binder EXPAND

On Thu, 15 Feb 2018 10:39:51 +0200, Binyamin Dissen wrote: >On Thu, 15 Feb 2018 02:14:35 -0600 Jerry Levine wrote: > >:>Is it possible to change the buffer address and LRECL before issuing the >PUTX? No. That would clobber the next record on the track. Or perhaps not fit on the track. > >You

Re: CKD #2 - KEY

W dniu 2018-02-14 o 17:12, Seymour J Metz pisze: Yes, you can allocate a nonVSAM file with a key area; why would you want to? For learning purposes. I have never done that. And in fact I'm not sure wether I still can. I tried with DSORG=PS and DA, and it seems everytime I get regular dataset

Re: CKD #2 - KEY

W dniu 2018-02-14 o 17:06, Pew, Curtis G pisze: On Feb 14, 2018, at 9:47 AM, R.S. wrote: 1. KEY Nowadays there are two "datasets" using hardware key: VTOC and PDS directory. What about other files? Is it possible to allocate new dataset with hardware key?

Re: DASD problem

Tommy, This should not be a surprise. The name "Synchronous Remote Copy" implies the overhead that you are seeing, namely the time for the synchronous write to the remote site. PPRC will more than double the response time of random writes because they the Host write to cache has the

Re: Coding the equivalent of a Binder EXPAND

Thanks, Binyamin. Back to the drawing board! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: DASD problem

Hi, The distance is around 30km, do you know any settings on sysplex environment such as GRS and JES2 checkpoint need to aware? Direct DASD via San switch to Dr site , 2GBPS interface , we check with vendor, they didn't find any problem on San switch or DASD, I suspect the system settings

Re: Coding the equivalent of a Binder EXPAND

On Thu, 15 Feb 2018 02:14:35 -0600 Jerry Levine wrote: :>I have an existing program which opens an elementary one-CSECT load module member in a PDS and GETs records until it comes to the CSECT's record, discernible by an eyecatcher at offset 0. :>Until now, the program

Coding the equivalent of a Binder EXPAND

Hi all, I have an existing program which opens an elementary one-CSECT load module member in a PDS and GETs records until it comes to the CSECT's record, discernible by an eyecatcher at offset 0. Until now, the program used the PUTX macro to update data in place in the existing record buffer.