Processor cache utilization

Dear all We have experienced increased CPU/transaction when the MVS busy is closed to 100%. We would like to measure the L1 and L2 processor cache utilization during these heavy CPU intervals. Could you please provide any method to measure processor cache performance? Kind regards Kostas

Re: TPROT Question

Okay got it thanks > On May 22, 2017, at 12:16 AM, Tony Harminc wrote: > >> On 21 May 2017 at 21:16, Joseph Reichman wrote: >> >> TPROT like the shift instruction second operand address is not used to >> address data rather for simplistic terms is

Re: TPROT Question

On 21 May 2017 at 21:16, Joseph Reichman wrote: > TPROT like the shift instruction second operand address is not used to > address data rather for simplistic terms is prog key checking if the user > can access/store the storage. > > So what If I am not sure what the key

TPROT Question

TPROT like the shift instruction second operand address is not used to address data rather for simplistic terms is prog key checking if the user can access/store the storage. So what If I am not sure what the key is. I guess I can do the following. Is my understanding ? Thanks

Re: Assembler addressing issue

Plus, not knowing all that is contained in the associated source, I would offer that one of the data elements in the dsect may be a referenced in subsequent code in such a manner as to require the data element to have already been defined. For example, if a dsect length were used in a length

Re: Sample JCL for file transfer using NJE/TCPIP

[Default] On 21 May 2017 13:28:35 -0700, in bit.listserv.ibm-main jesse1.robin...@sce.com (Jesse 1 Robinson) wrote: >RACF data base is not required to be PSU. PS with RECFM F is fine. RACF >predates VSAM. > Since VSAM came in with virtual storage, are you saying RACF was on OS360? Clark Morris

SRB question

Hi I was under the impression that when you scheduled a SRB with the STOEKN parm either on the SCHEDULE macro or on the IEAMSCHED macro the address space where you invoke the SCHEDULE/IEAMSCHED is The HOME asid and where the SRB runs is the primary. Now looking at the authorized assembler

Re: Assembler addressing issue

On 21 May 2017 at 15:24, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Sun, 21 May 2017 14:37:08 +0300, Binyamin Dissen wrote: > > >I fail to understand why you are placing the macro in the middle of your > >workarea. I would typically place all mapping macroes in a

Re: Sample JCL for file transfer using NJE/TCPIP

RACF data base is not required to be PSU. PS with RECFM F is fine. RACF predates VSAM. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original

Re: SDB (system determined Blksize)

On 2017-05-21, at 10:15, Jesse 1 Robinson wrote: > > So why not define all blocks as 32K? For other than FB, that makes sense, and > SDB algorithms take that into account. For RECFM FB, however, there would be > an egregious amount of unusable space on each 3390 track. Nothing in z >

Re: Assembler addressing issue

On Sun, 21 May 2017 14:37:08 +0300, Binyamin Dissen wrote: >I fail to understand why you are placing the macro in the middle of your >workarea. I would typically place all mapping macroes in a block at the end >of the program (though others prefer the top). > >Do you do the same with other

Re: Sample JCL for file transfer using NJE/TCPIP

On Sun, 21 May 2017 05:12:00 -0500, Elardus Engelbrecht wrote: > >>RACF (I'm less sure) is VSAM. > >No, it is PSU (PS and Unmovable). Other attributes are mandated by IBM. > "Unmovable" would seem to imply uncopyable; the copy would have to go in a different place. But there must be some

Missing JES2 List (Was Removing JES2 PRT and RMT definitions)

I have been doing some checking. I can reset my password and logon to the JES2 list on Virginia Tech ListServer. But for some reason, that and a lot of others Lists are missing. Subscribe or Unsubscribe to the JES2-L List There is no JES2-L list on this server. Try sending a "LIST"

Re: The Mainframe vs. the Server Farm: A Comparison

dcrayf...@gmail.com (David Crayford) writes: > It's a risky business migrating large systems and many have failed. I > know of one bank that spent $350M trying and they failed > miserably. There are just so many complexities and it's just too hard > for most. > I heard an amusing analogy that it's

Re: Sample JCL for file transfer using NJE/TCPIP

For a truly first class solution--at a first class price--there's Connect Direct (formerly NDM). Connect Direct offers guaranteed delivery even across IPL outages. It also works between z/OS and UNIX. The product has to be functional at both ends, likely increasing the cost further. . .

Re: Removing JES2 PRT and RMT definitions

I was hoping that Tom W. or someone else from JES2 would chime in. I don't recall having removed JES2 devices in a MAS, but I'll go out on a limb with the observation that all-systems warm start is hardly ever required for anything these days. Since the advent of dynamic modification in the

Re: SDB (system determined Blksize)

The first (maybe only) hardware I know of that claimed no wasted space was STK Iceberg, which was touted as being so virtual that an emulated 3390 track actually left no unused track bits. I never worked with one, but I heard horror stories about *all* the data getting wasted when the Iceberg

Re: Cobol-calling-Asembler and 24bit mode

Charles, Thank you ..I am looking at the pdf you sent ...excellent ... On Sat, May 20, 2017 at 3:54 PM, Charles Mills wrote: > Is my understanding correct? > > - the call from COBOL to assembler is dynamic; that is, the assembler > programs are separately linkedited

Re: SDB (system determined Blksize)

As I said, I am no expert. My point was simply to give an example to illustrate the answer to > Where would it be assigned or accounted for? If you ignored such > waste, you could have more capacity available than the volumes > you've defined. and illustrate that defined apparent 3390 space

Re: Assembler addressing issue

I fail to understand why you are placing the macro in the middle of your workarea. I would typically place all mapping macroes in a block at the end of the program (though others prefer the top). Do you do the same with other mapping macroes that generate DSECTs? What do you expect this to

Re: Assembler addressing issue

Binyamin, I have done this by definning the text units in non dynamic area and copying the content into dynamic area own dsect. This was not my problem. I just had to resume addressing as John proposed. Thanks. ITschak בתאריך 21 במאי 2017 13:52,‏ "Binyamin Dissen"

Re: Assembler addressing issue

On Sun, 21 May 2017 10:22:49 +0300 IronSphere by SecuriTeam Software wrote: :>It look like I haven't done that for a while... anyway, I am writing an :>assembler, reentrent, program that performs dynamic allocation, open, read, :>close, dynamic WTO, etc. It work fine as a non

Re: Assembler addressing issue

Thanks John, I should have remember it. I resume the main csect that way... ITschak On Sun, May 21, 2017 at 1:15 PM, John Gateley wrote: > Hi > > Try re-establishing the DSECT like this > > DYNAREA DSECT > AAA DS .. > BBB DS.. > ​ IEFZB4D0

Re: Assembler addressing issue

Hi Try re-establishing the DSECT like this DYNAREA DSECT AAA DS .. BBB DS.. ​ IEFZB4D0 DYNAREA DSECT DYNMSG WTO...,MF=L John -- For IBM-MAIN subscribe / signoff / archive access

Re: Sample JCL for file transfer using NJE/TCPIP

Paul Gilmartinwrote: >>Yes, I am using FTP to transfer my SMF data, RACF DB, etc. from several LPARs >>to one LPAR, simply for archival purposes. >>I can supply a sample JCL for FTP of SMF data if you wish to experiment with >>that. >I'll not ask for JCL; I won't use it. This is fine. You

Assembler addressing issue

It look like I haven't done that for a while... anyway, I am writing an assembler, reentrent, program that performs dynamic allocation, open, read, close, dynamic WTO, etc. It work fine as a non reentrent program, but when I convert to reentrent code, I am loosing addressability for some of my