Re: Master Address space - High Paging

RMF II background session ASD A,A, ALL and ARD A, A, ALL at 10 second intervals or less. Best served with MXG. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Sent: Thursday, April 28, 2016 2:44 AM To: IBM-MAIN@LISTSERV.UA.EDU

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

On 2016-04-29, at 15:06, R.S. wrote: >> >> Works for me. > You are right. Please rerun the job. I bet you'll get SB214 abend. > I know that well. I assumed that since the OP's requirement was to avoid overwriting an existing member, SB214 would meet his need. I had considered the

Re: Following IBM-MAIN on iOS (or Android, for that matter)

Silly me (perhaps): It seems if I change to my IBM-MAIN mail folder from my Inbox all the newsgroup conversations show up. What threw me was this stuff doesn't show up if I stick in my Inbox. Hmmm. Sent from my iPad > On 29 Apr 2016, at 18:53, Martin Packer wrote: >

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

W dniu 2016-04-29 o 22:30, Paul Gilmartin pisze: On 2016-04-29, at 09:58, R.S. wrote: That deserves an SR. Works in JCL; works everywhere else. The statement is patently false. No, it isn't. MOD is not allowed for *member* od PDS or PDSE. MOD is allowed for PO dataset, i.e. for IEFBR14

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

On 2016-04-29, at 09:58, R.S. wrote: >>> >>> That deserves an SR. Works in JCL; works everywhere else. The statement is >>> patently false. >> No, it isn't. MOD is not allowed for *member* od PDS or PDSE. >> MOD is allowed for PO dataset, i.e. for IEFBR14 MOD,DELETE >> >> Try IEBGENER

zTPF questions (and VSE)

Just curious: what is the price of z/TPF system? AFAIKit is licensed as z/OS (MLC, charges based on MSU 4HRA). I'd like to know how it's related to z/TPF price. Is it cheaper than z/OS? How much? Another question: what is typical size of TPF LPAR in terms of MSU/MIPS and central memory?

Re: Alter access to datasets

Perhaps the link folding. Try this: http://tinyurl.com/hnx4k4p Can you audit down to the level of saying "Joe Sysprog changed record 247 of this dataset"? No. Down to the member level of PDS(E)'s and down to the table of DB2 -- that's the limits of the granularity. Charles -Original

Re: Alter access to datasets

Did you see the wrap? http://s23.a2zinc.net/clients/SHARE/Winter2016/Public/SessionDetails.aspx?FromPage=Sessions.aspx=312=8 Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of gsg > Sent: Friday, April 29, 2016 12:02 PM >

Re: Scheduled STCs running as instream procs?

A started job will not tell you from where it came. On the other hand, it will also not say instream. Willy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the

Re: How to copy one pack IPL'able z/OS to DVD.

Count me in! I have 2 B's and a 3 right now looking forward to getting a Pi zero when they come back in stock with the new 'mystery' feature Dana On Fri, 29 Apr 2016 08:54:41 -0700, Tom Brennan wrote: >David Crayford wrote: >> >> I've got a Pi3! Are we

Re: Alter access to datasets

Unable to access the first link tot he Share doc. Does this auditing go down to the record level? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO

Re: Following IBM-MAIN on iOS (or Android, for that matter)

I wouldn't - if the IBM-MAIN folder I have a Notes rule for actually sent stuff to iOS email (like my Inbox). Sounds like a configuration problem. I just wondered if there was a better way. Martin Packer, zChampion, Principal Systems Investigator, Worldwide Cloud & Systems Performance, IBM

Re: Alter access to datasets

I've got a horse in this race (http://s23.a2zinc.net/clients/SHARE/Winter2016/Public/SessionDetails.aspx?F romPage=Sessions.aspx=312=8) but you might consider real-time auditing of ALTER access to the datasets as a way of mitigating the risk (for the auditors). We also have an installation that

Re: Alter access to datasets

Does anyone know if the STGADMIN Facility Class will allow the Storage Guys to ALTER a dataset that they do not have direct access to? The RACF Administrator thought we could remove the ALTER access from our SYSPROGs and that the Storage guys could ALTER in the event of problems. ex. running

Re: Alter access to datasets

ex. CAI.OPS.OPSLOG or COMPWARE.LMS.CHKPTA The concern is someone will do something and try to delete a log entry to cover their tracks. These are mostly ISV products that I'd think would be tracked in SMF records. My thought would be to accept the risk, since these are not critical datasets.

Re: An explanation for branch performance?

On 29 April 2016 at 12:59, Jim Mulder wrote: > The relevant comparison is not conditional branch vs. > unconditional branch. It is branch not taken vs. branch taken. > Sequential execution is always best. Branch prediction tries to > mitigate some of the effects of

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

This is what I have. In the Data set name type ===> it is blank as shown below. Data set name  ===> ''SYS2.BATCH.JOBS.OUTPUT'                                    Member to use  ===> JOB06703                                                  Disposition    ===> SHR        (OLD, NEW,

Re: An explanation for branch performance?

> >> Good point well made but can you explain why changing a B to a BE > in a tight loop results in 43% difference? > > But aren't those two completely different cases (even if it is the > same instruction)? The first is an unconditional branch, the second > one a conditional branch. That

Re: Following IBM-MAIN on iOS (or Android, for that matter)

On 29 April 2016 at 02:23, Martin Packer wrote: > Other than using an email client on iOS has anyone found a good way of > participating in LISTSERV groups on iOS? > > To keep this interesting for about half of y'all, same question for Android. I don't use Apple

Re: An explanation for branch performance?

>> I assume it is 43% faster than the conditional one? If it is the other way >> around I will be very surprised as well. > > No. It's the opposite which is why I originally posted. The unconditional > branch is slower and I want to know why. That's probably 'a branch not taken is always faster

Re: An explanation for branch performance?

On 29 April 2016 at 12:06, David Crayford wrote: > On 29/04/2016 11:55 PM, Tony Harminc wrote: >> >> On 29 April 2016 at 11:50, Charles Mills wrote: >>> >>> What about substituting a branch relative for the branch on base >>> register? Trivial code change

Re: An explanation for branch performance?

On 30/04/2016 12:29 AM, Windt, W.K.F. van der (Fred) wrote: Good point well made but can you explain why changing a B to a BE in a tight loop results in 43% difference? But aren't those two completely different cases (even if it is the same instruction)? The first is an unconditional branch,

Re: Following IBM-MAIN on iOS (or Android, for that matter)

On Fri, 29 Apr 2016 07:23:35 +0100, Martin Packer wrote: >I've participated in IBM-MAIN for MANY years - from my laptop email >client. > >Other than using an email client on iOS has anyone found a good way of >participating in LISTSERV groups on iOS? > >To keep this

Re: An explanation for branch performance?

> > Good point well made but can you explain why changing a B to a BE in a tight > loop results in 43% difference? But aren't those two completely different cases (even if it is the same instruction)? The first is an unconditional branch, the second one a conditional branch. That probably

Re: An explanation for branch performance?

On 30/04/2016 12:23 AM, Windt, W.K.F. van der (Fred) wrote: Sent from my new iPad On 29 Apr 2016, at 18:10, Peter Relson wrote: Since the origin for the starting post apparently lay in branching around the eyecatcher (which really is not necessarily at all the same as a

Re: An explanation for branch performance?

Sent from my new iPad > On 29 Apr 2016, at 18:10, Peter Relson wrote: > > Since the origin for the starting post apparently lay in branching around > the eyecatcher (which really is not necessarily at all the same as a > branch in a 2 instruction loop), I was surprised that

Re: An explanation for branch performance?

On 30/04/2016 12:10 AM, Peter Relson wrote: Since the origin for the starting post apparently lay in branching around the eyecatcher (which really is not necessarily at all the same as a branch in a 2 instruction loop), I was surprised that none of the posts that I glanced at mentioned

Re: An explanation for branch performance?

Since the origin for the starting post apparently lay in branching around the eyecatcher (which really is not necessarily at all the same as a branch in a 2 instruction loop), I was surprised that none of the posts that I glanced at mentioned Instruction-cache misses. Just because you think

Re: An explanation for branch performance?

On 29/04/2016 11:55 PM, Tony Harminc wrote: On 29 April 2016 at 11:50, Charles Mills wrote: What about substituting a branch relative for the branch on base register? Trivial code change to make. I was about to suggest that too. All the IBM published material I've seen on

Re: How to copy one pack IPL'able z/OS to DVD.

It's Friday... 1. I would like to have whole z/OS installation material (read tape content) on pendrive. I could accept multiple volumes (pendrives) instead of single bigger one. BTW: It's cheaper than tape cart, 32GB one is for less than 10$. 2. I would like to have another pendrive(s) for

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

(resend, please be patient if got two copies) W dniu 2016-04-29 o 17:37, R.S. pisze: W dniu 2016-04-29 o 17:31, Paul Gilmartin pisze: On Fri, 29 Apr 2016 11:49:57 +, willie bunter wrote: Paul. I tried out your suggestion using disp=mod however it doesn't work : MOD NOT ALLOWED FOR PDS

Re: An explanation for branch performance?

On 29 April 2016 at 11:50, Charles Mills wrote: > What about substituting a branch relative for the branch on base register? > Trivial code change to make. I was about to suggest that too. All the IBM published material I've seen on this suggests that -- all else being equal

Re: How to copy one pack IPL'able z/OS to DVD.

David Crayford wrote: I've got a Pi3! Are we nerds? Me too! Yes, you didn't know? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: An explanation for branch performance?

On Fri, Apr 29, 2016 at 9:30 AM, John McKown wrote: > On Fri, Apr 29, 2016 at 9:27 AM, Mike Schwab > wrote: > >> Well, the obvious solution is to code the eyecatcher literals before >> the entry point. It will be less obvious that the

AW: Re: An explanation for branch performance?

>> >> L R4,=A(1*1000*1000*1000) >> LTR R4,R4 >> J LOOP >> * >> LOOP DS 0D .LOOP START >> B NEXT >> >> NEXT JCT R4,LOOP > > The loop starts with a branch ... I tested it twice - when the CC is matched > (branch

Re: An explanation for branch performance?

On 29/04/2016 11:40 PM, Jim Mulder wrote: Well, the obvious solution is to code the eyecatcher literals before the entry point. It will be less obvious that the eyecatcher is part of the program (and not the end of the previous program) but as the technique become more widespread it should

Re: An explanation for branch performance?

I think all issues of this general type are incredibly difficult to analyze reliably because the hardware is so darned complex now. There are so many more variables than back in the day when you could say "a branch consumes 'n' microseconds" or "'n' microseconds if taken, 'm' microseconds if

Re: An explanation for branch performance?

This is very interesting. It explains what I thought was an anomaly of the CA TriTune product, which we use here for profiling our in-house code. Strictly enforced standards here require inclusion of automatically customized code at the start of every COBOL procedure (main or subroutine) that

Re: OA49446 on RSU1603 - RACF / DFSMS change

On Fri, 29 Apr 2016 07:15:09 -0400, Robert S. Hansel (RSH) wrote: >(Cross-posting to RACF-L) > >Mark, > > >If this works as per my interpretation, then I think the concerns raised by >others are > valid. If I can create an alias with a name to which I have access

Re: An explanation for branch performance?

Try this on your hardware and post the results. Uncomment/Comment where applicable. BENCHCSECT BENCHAMODE 31 SAVE (14,12) LRR12,R15 USING BENCH,R12 L R4,=A(1*1000*1000*1000) LTR R4,R4 J LOOP * LOOP DS 0D

Re: any need?

Google 'SMF Log Streams'. If I'm not mistaken, there's a Redbook on this very subject. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: An explanation for branch performance?

Try this on your hardware and post the results. Uncomment/Comment where applicable. BENCHCSECT BENCHAMODE 31 SAVE (14,12) LRR12,R15 USING BENCH,R12 L R4,=A(1*1000*1000*1000) LTR R4,R4 J LOOP * LOOP DS 0D

Re: An explanation for branch performance?

> >> Well, the obvious solution is to code the eyecatcher literals before > >> the entry point. It will be less obvious that the eyecatcher is part > >> of the program (and not the end of the previous program) but as the > >> technique become more widespread it should become more trusted. > >> >

Re: An explanation for branch performance?

Plus it's really not an assembler question. The assembler is a program that turns 'B' into '47F0'. This is a hardware performance question. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Friday,

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

On Fri, 29 Apr 2016 11:49:57 +, willie bunter wrote: >Paul. > >I tried out your suggestion using disp=mod however it doesn't work : MOD NOT >ALLOWED FOR PDS > ??? That deserves an SR. Works in JCL; works everywhere else. The statement is patently false. -- gil

Re: An explanation for branch performance?

On 29/04/2016 11:10 PM, Lizette Koehler wrote: Maybe the IBM Assembler List might be helpful here? If you have not joined, use this URL: https://listserv.uga.edu/cgi-bin/wa?A0=ASSEMBLER-LIST Lizette See my earlier response to Elardus. The assembler list is almost

Re: How to copy one pack IPL'able z/OS to DVD.

On Fri, Apr 29, 2016 at 9:47 AM, John Eells wrote: > John McKown wrote: > > > What we have today for the Customized Offerings Driver in DVD format is: > > - An IPLable copy of standalone DFSMSdss on a DVD > - Dump files for the z/OS COD system on DVDs > - The capability with

Re: An explanation for branch performance?

On 29/04/2016 10:27 PM, Mike Schwab wrote: Well, the obvious solution is to code the eyecatcher literals before the entry point. It will be less obvious that the eyecatcher is part of the program (and not the end of the previous program) but as the technique become more widespread it should

Re: An explanation for branch performance?

Maybe the IBM Assembler List might be helpful here? If you have not joined, use this URL: https://listserv.uga.edu/cgi-bin/wa?A0=ASSEMBLER-LIST Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of

Re: An explanation for branch performance?

On 29/04/2016 10:30 PM, John McKown wrote: On Fri, Apr 29, 2016 at 9:27 AM, Mike Schwab wrote: Well, the obvious solution is to code the eyecatcher literals before the entry point. It will be less obvious that the eyecatcher is part of the program (and not the end of

Re: An explanation for branch performance?

On 29/04/2016 9:35 PM, Windt, W.K.F. van der (Fred) wrote: Here's the code. I wrote a simple program - it tight loops 1 billion times L R4,=A(1*1000*1000*1000) LTR R4,R4 J LOOP * LOOP DS 0D .LOOP START B NEXT

Re: 64-bit caller and VL-bit

Paul Gilmartin wrote: And the UNIX argv[] vector is terminated by a NULL (0) pointer, not -1. John McKown wrote: I am under the distinct impression that the number of elements in argv[] is the value in argc. You're both right.

Re: An explanation for branch performance?

On 29/04/2016 10:34 PM, Joe Testa wrote: There seems to be little point worrying about the time needed to branch past an eyecatcher at the start of a program, compared to the time used by the rest of the program. Unfortunately that's not true. For high frequency subroutines it can dominate

Re: How to copy one pack IPL'able z/OS to DVD.

John McKown wrote: I can, vaguely, imagine PR/SM​ being able to have a special LPAR type (conceptually like a CF LPAR) which could have a smart enough system on it to be bootable (like CF) and has "utilities" on it to initialize DASD, then install the base version _any_ IBM OS over the

Re: An explanation for branch performance?

On Fri, Apr 29, 2016 at 9:27 AM, Mike Schwab wrote: > Well, the obvious solution is to code the eyecatcher literals before > the entry point. It will be less obvious that the eyecatcher is part > of the program (and not the end of the previous program) but as the >

Re: An explanation for branch performance?

There seems to be little point worrying about the time needed to branch past an eyecatcher at the start of a program, compared to the time used by the rest of the program. From: Mike Schwab Sent: Friday, April 29, 2016 10:27 AM Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@LISTSERV.UA.EDU

Re: An explanation for branch performance?

Well, the obvious solution is to code the eyecatcher literals before the entry point. It will be less obvious that the eyecatcher is part of the program (and not the end of the previous program) but as the technique become more widespread it should become more trusted. On Fri, Apr 29, 2016 at

Re: 64-bit caller and VL-bit

On Thu, Apr 28, 2016 at 5:40 PM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > This has the collateral boon that you can code an empty 64-bit parameter > list, something not possible with a 24-bit or 31-bit parameter list. > > But IBM should formalize the convention.

Re: How to copy one pack IPL'able z/OS to DVD.

How would one do that? Are there instructions in the manual? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Friday, April 29, 2016 9:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to copy one pack IPL'able

Re: An explanation for branch performance?

On 29/04/2016 10:09 PM, Mike Schwab wrote: The pipeline is optimized for running many instructions in a row. A branch is not recognized until through a good part of the pipeline. Meanwhile the data to be skipped is in the instruction pipeline. Results meet expectations. So branching over

Re: An explanation for branch performance?

> Here's the code. > > I wrote a simple program - it tight loops 1 billion times > > > L R4,=A(1*1000*1000*1000) > LTR R4,R4 > J LOOP > * > LOOP DS 0D .LOOP START > B NEXT > > NEXT JCT R4,LOOP > > The loop

Re: An explanation for branch performance?

The pipeline is optimized for running many instructions in a row. A branch is not recognized until through a good part of the pipeline. Meanwhile the data to be skipped is in the instruction pipeline. Results meet expectations. On Fri, Apr 29, 2016 at 7:40 AM, David Crayford

Re: How to copy one pack IPL'able z/OS to DVD.

On Thu, Apr 28, 2016 at 8:55 PM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > Blu-ray? > > -- gil I think they are around 25GB. Why not an ADRDSSU IPLable backup tape image of a RESCUE volume? We use mirrored VTAPE and restore from it, no mirrored DASD. -- Mike A

Re: How to copy one pack IPL'able z/OS to DVD.

On 29/04/2016 9:41 PM, John McKown wrote: ​on my Intel PC. On my newest Raspberry Pi3, it came with a micro SD card. The Pi3 boots from it. The supplied boot image simply puts up a splash screen asking what you want to install from the menu, you select, it downloads and installs it. You then

Re: How to copy one pack IPL'able z/OS to DVD.

(multi-posted from thread started on IBM-MAIN) An interesting idea in the last paragraphs? "Tooting own horn" On Thu, Apr 28, 2016 at 9:18 PM, Rob Schramm wrote: > Cloud? > > Rob > > ​For installation? Why not. I can do a "PXE net boot" using an ethernet card​ ​on my

Re: An explanation for branch performance?

On 29/04/2016 9:08 PM, Vernooij, CP (ITOPT1) - KLM wrote: I wonder if it is really a 'problem'. What kind of mormal program does this amount of branches back to where it just came from, messing up the entire pipeline. Is it efficient to optimize a z13 for this kind of programs? Isn't it

Re: 64-bit caller and VL-bit

On 29/04/2016 8:59 PM, Bernd Oppolzer wrote: Thank you. Some of the versions of GCC that I use also checks the arguments of printf etc. using the first parameter string constant, if available. When moving programs from OS/2 to Linux, I discovered some hidden errors this way. IIRC clang

Re: WLM issue with a proposed solution

Thanks! One note on SYSSTC: Whether the velocity GOAL of "STCHI" matches the MEASURED velocity of SYSSTC or not the latter is still protected relative to the former. Sensitised to this because a recent customer situation saw DBM1 in SYSSTC, competing with IRLM. I normally - in my graphing at

Re: An explanation for branch performance?

I wonder if it is really a 'problem'. What kind of mormal program does this amount of branches back to where it just came from, messing up the entire pipeline. Is it efficient to optimize a z13 for this kind of programs? Isn't it better to optimize for the millions of other programs who are

Re: An explanation for branch performance?

On 29/04/2016 8:46 PM, Elardus Engelbrecht wrote: David Crayford wrote: We're doing some performance work on our assembler code and one of my colleagues ran the following test which was surprising. Unconditional branching can add significant overhead. I always believed that conditional

Re: WLM issue with a proposed solution

Thank you all for chiming in! Yeah the bottom line... figure out why those sub second transactions get stalled! Hard to tune your way out of a locking condition :-) I will check out the SYSSTC actual velocity... that is a good bench mark to what my max achievable would be around. Happy

Re: 64-bit caller and VL-bit

That's an excellent answer Bernd! One of the reasons why I prefer C++ over C is that iostreams are not only typesafe but they handle variable length parameter lists by simple function calls. The downside is that the extra function call overhead is more expensive so it's a trade-off. It's also

Re: An explanation for branch performance?

David Crayford wrote: >We're doing some performance work on our assembler code and one of my >colleagues ran the following test which was surprising. Unconditional >branching can add significant overhead. I always believed that conditional >branches were expensive because the branch predictor

Re: 64-bit caller and VL-bit

There is no defined standard for marking the end of a variable length parameter (address) list in C. The header includes functions that allow for variable number of parameters, but then you have to have a first parameter (or first set of parameters) that allows you to determine the number of

An explanation for branch performance?

We're doing some performance work on our assembler code and one of my colleagues ran the following test which was surprising. Unconditional branching can add significant overhead. I always believed that conditional branches were expensive because the branch predictor needed to do more work and

Re: OA49446 on RSU1603 - RACF / DFSMS change

On Fri, 29 Apr 2016 07:21:12 -0500, Tom Marchant wrote: >The old way, which surprises me a little, DEFINE ALIAS required access to the >data set to which the alias is related, but not to the alias name being >defined. Sorry, this part seems to be incorrect. The old way didn't require any

Re: OA49446 on RSU1603 - RACF / DFSMS change

On Thu, 28 Apr 2016 12:01:17 -0500, Mark Zelden wrote: >I'm applying z/OS 2.1 RSU1603 and came across this PTF. Is anyone running >with >it in production and has it caused you any grief? This seems to change a >behavior >that has been around "forever", so it concerns me a bit even though

Re: 64-bit caller and VL-bit

What I'm curious about is: _what does XLC do?_ -- R; <>< On 04/28/16 19:15, Charles Mills wrote: As a C/C++ convert, I like 0_0 (NULL in C lingo) better than _ (only because it is a widely-used convention in C). (OTOH FFF... is widely-used in CMS.) Agree with Gil's

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

Paul. I tried out your suggestion using disp=mod however it doesn't work : MOD NOT ALLOWED FOR PDS On Thu, 4/28/16, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: Subject: Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF To:

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

Data set name ===> 'ABCDE.FGHIJK.LMNOP' Member to use ===> QRSTUV Disposition===> NEW(OLD, NEW, SHR, MOD)

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

Lizette, I tried your suggestion using NEW but it doesn't work. I get the message MEMBER NAME NOT ALLOWED I hit the PF1 option but it wasn't much help. On Thu, 4/28/16, Lizette Koehler wrote: Subject: Re: SAVING JOB

Re: OA49446 on RSU1603 - RACF / DFSMS change

(Cross-posting to RACF-L) Mark, I have not worked with this APAR and PTF. Below is my interpretation of it. I agree this is a huge change. I think careful testing is needed to confirm this, and as I don't have access to a system with the change, I would be happy to help you with the test out

Re: TSO command from Microsoft Windows

Timothy Sipples wrote: >>Are there any stats on the number of z/OS installs and the number of installs >>that are using z/OSMF? >The direct answer is no. Actually yes, but NEVER made public. This question has been asked many times without any definitive answers. >IBM obviously has

Re: WLM issue with a proposed solution

>If your batch jobs are running Dicretionary at a DP lower than CICS, it is >very >unlikely that they are causing significant CICS delays. True from a CPU perspective. But the batch jobs could be locking resources in DB2 that are delaying the CICS transactions. And if the batch jobs holding

Re: TSO command from Microsoft Windows

Rob Schramm asked: >Are there any stats on the number of z/OS installs and the number of >installs that are using z/OSMF? The direct answer is no. IBM obviously has statistics on the number of authorized z/OS licensees. It's possible to estimate the number of z/OS installs, but it'd be only an

Re: SAVING JOB OUTPUT IN A PDSE FROM SDSF

No, you cannot prevent it. Been there... -- Radoslaw Skorupka Lodz, Poland W dniu 2016-04-29 o 00:59, willie bunter pisze: Hallo All, I need your suggestions. I am savings job output in a PDSE using SDSF. The member name I use is the job number e.g. Member to use ===> JOB067XX I am

Re: AXR04 System REXX

Thank you for the heads-up. A coworker is installing it as I type. I'll now go RTFMs and browse the 2.2 parmlib. :-) Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Anthony Thompson Sent: Thursday, April 28, 2016 9:40 PM To:

Re: Following IBM-MAIN on iOS (or Android, for that matter)

I use a dedicated email address. It is accessible from my iPhone and W7 PC. Linda Sent from my iPhone > On Apr 29, 2016, at 12:39 AM, Elardus Engelbrecht > wrote: > > Martin Packer wrote: > >> I've participated in IBM-MAIN for MANY years - from my laptop

Re: Following IBM-MAIN on iOS (or Android, for that matter)

Martin Packer wrote: >I've participated in IBM-MAIN for MANY years - from my laptop email client. Excellent! And I learn from your posts! >Other than using an email client on iOS has anyone found a good way of >participating in LISTSERV groups on iOS? What about using the browser (Safari?)

Re: Following IBM-MAIN on iOS (or Android, for that matter)

On 29/04/2016 2:23 PM, Martin Packer wrote: I've participated in IBM-MAIN for MANY years - from my laptop email client. Other than using an email client on iOS has anyone found a good way of participating in LISTSERV groups on iOS? I've used NewsTap on my iPad but TBH it's not really a step

Re: Alter access to datasets

gsg wrote: >As part of a systems programmer duties, they have ALTER access to many >datasets. They need/require this access to install, upgrade, maintain and >resolve problems. Audit has been pushing more and more to remove the ALTER >access. >Has anyone else been experiencing this? Nearly

Re: WLM issue with a proposed solution

Agree: "Achievable" is what's important here. Please measure it - with load. This is where I struggle without IBM-MAIN being a visual medium. :-) I plot velocity WITH LOAD and see how it droops. My code has done this for years and I present this graphing method regularly - to individual

Following IBM-MAIN on iOS (or Android, for that matter)

I've participated in IBM-MAIN for MANY years - from my laptop email client. Other than using an email client on iOS has anyone found a good way of participating in LISTSERV groups on iOS? To keep this interesting for about half of y'all, same question for Android. Use case: Mental

Re: WLM issue with a proposed solution

My experience is that CICS will suffer if the LPAR is being soft capped, no matter what you try to do to this situation. So I think the best and only solution is to avoid that the LPAR becomes capped by keeping the batch consumption under control. Not with a limited number of initiators,