Re: Mainframes testing

[Lennie Dymoke-Bradshaw]

Filip,

The IBM paper reads as if it has been written by someone with relatively little 
System z knowledge.

" There can also be security flaws created during the
set-up of permissions for libraries. Libraries are modules for
coding. They call into the code and should only be accessed
by people who have the highest level of permission."

I am not even sure what the above means.

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Filip Palian
Sent: 13 August 2019 02:17
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Mainframes testing

Hey List,

This can be of interest to some:

- 
https://securityintelligence.com/posts/top-five-security-focus-areas-for-mainframes/
- https://www.ibm.com/downloads/cas/A9NKZ8WE

Any thoughts/comments?


Thanks,
Filip

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

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

Re: NTP Server connectivity quandary

[Dana Mitchell]

On Mon, 12 Aug 2019 21:08:58 +, Mark Jacobs  
wrote:
>
>Went back to the Sysplex time task, used that IP address as the ETS source, 
>same communications failure.
>
>I'm at a loss.
>

Me too, thats how ours are set up.  Do you have the STP feature?  (is it 
optional on z13?).   Defined CPCs -> right click on selected CPC -> System 
Details -> STP Information tab.  What all does it say for the Timing state and 
mode?

Dana

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

Re: NTP Server connectivity quandary

[Mark Jacobs]

Yes. We have STP.

It's currently unconfigured. I'm waiting until I get NTP services setup before 
I setup the CTN.

Timing network type: Unconfigured
Coordinated timing network (CTN) ID:

Timing state:   Unsynchronized
Usable clock source:No
Timing mode:Local
Maximum timing stratum level:   3
Maximum STP version:4

We're likely going to ping our hardware support company next.

Thanks for your assistance.

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, August 13, 2019 8:25 AM, Dana Mitchell  wrote:

> On Mon, 12 Aug 2019 21:08:58 +, Mark Jacobs markjac...@protonmail.com 
> wrote:
>
> > Went back to the Sysplex time task, used that IP address as the ETS source, 
> > same communications failure.
> > I'm at a loss.
>
> Me too, thats how ours are set up. Do you have the STP feature? (is it 
> optional on z13?). Defined CPCs -> right click on selected CPC -> System 
> Details -> STP Information tab. What all does it say for the Timing state and 
> mode?
>
> Dana
>
> ---
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Mainframes testing

[Aled Hughes]

 You and me both Lennie 

"Abby is a seasoned marketing and public relations professional."
Reminds me that a journalist called Ruth Sunderland was on the radio the other 
day stating that the airline British Airways (after a failure) "is riddled with 
old systems that have been in place for many years and have become creaky and 
inefficient. Replacing them without major disruptions is a Herculean job." She 
even stated that 'mainframes' were to blame for the 2018 TSB fiasco. 

As someone recently said, "We have a dearth of experts commenting on the 
mainframe world, without knowing anything about mainframes."
ALH






 
 
-Original Message-
From: Lennie Dymoke-Bradshaw 
To: IBM-MAIN 
Sent: Tue, 13 Aug 2019 10:29
Subject: Re: Mainframes testing

Filip,

The IBM paper reads as if it has been written by someone with relatively little 
System z knowledge.

" There can also be security flaws created during the
set-up of permissions for libraries. Libraries are modules for
coding. They call into the code and should only be accessed
by people who have the highest level of permission."

I am not even sure what the above means.

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Filip Palian
Sent: 13 August 2019 02:17
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Mainframes testing

Hey List,

This can be of interest to some:

- 
https://securityintelligence.com/posts/top-five-security-focus-areas-for-mainframes/
- https://www.ibm.com/downloads/cas/A9NKZ8WE

Any thoughts/comments?


Thanks,
Filip

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

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

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

Re: Source of initial HMC backup

[Christian Svensson]

Hi,

I managed to get a backup going by copying /console/data/iqyvpdc.xml from
my SE to my HMC and then running the backup. It seems to work just fine,
but if anyone can confirm / deny the sanity of doing that it would be
greatly appreciated :-).

Thanks,

On Mon, Aug 12, 2019 at 6:12 PM Christian Svensson  wrote:

> Hi,
>
> Yes - the drive is formatted and it shows up correctly. If I do not have
> it formatted it fails earlier in the process.
> I'm starting to suspect something is off with the VPD data. The little
> information I could find was from the
> "repair problem" flow that suggested that I replace the component named
> something like "VPD file".
>
> I managed to run backupccdata from a root shell on the HMC and it also
> complains about VPD.
> "VPD file: /console/data/iqyvpdc.xml was not found in the HDD, fail Backup
> script".
>
> Doing a "Rebuild VPD" on the CPC fails however, but maybe that's where I
> should be focusing
> my efforts?
>
> Thanks,
>
>
>
> On Mon, Aug 12, 2019 at 5:53 PM Dana Mitchell  wrote:
>
>> Did you format the USB using the 'Format Media' task in Console Actions?
>>
>> Dana
>>
>> On Mon, 12 Aug 2019 17:36:35 +0200, Christian Svensson 
>> wrote:
>> >
>> >Is there a way I can create this initial backup USB so I can make the HMC
>> >happy?
>> >
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>

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

Re: Mainframes testing

[Lennie Dymoke-Bradshaw]

It would nice to think that IBM could comment on their own platform with a 
little more authority and accuracy. After all System z income has sustained IBM 
over the last 25 years. Without the enormous annuity income from their System z 
customers IBM would have gone down the tubes years ago.

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Aled Hughes
Sent: 13 August 2019 13:54
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Mainframes testing

 You and me both Lennie 

"Abby is a seasoned marketing and public relations professional."
Reminds me that a journalist called Ruth Sunderland was on the radio the other 
day stating that the airline British Airways (after a failure) "is riddled with 
old systems that have been in place for many years and have become creaky and 
inefficient. Replacing them without major disruptions is a Herculean job." She 
even stated that 'mainframes' were to blame for the 2018 TSB fiasco. 

As someone recently said, "We have a dearth of experts commenting on the 
mainframe world, without knowing anything about mainframes."
ALH






 
 
-Original Message-
From: Lennie Dymoke-Bradshaw 
To: IBM-MAIN 
Sent: Tue, 13 Aug 2019 10:29
Subject: Re: Mainframes testing

Filip,

The IBM paper reads as if it has been written by someone with relatively little 
System z knowledge.

" There can also be security flaws created during the set-up of permissions for 
libraries. Libraries are modules for coding. They call into the code and should 
only be accessed by people who have the highest level of permission."

I am not even sure what the above means.

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Filip Palian
Sent: 13 August 2019 02:17
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Mainframes testing

Hey List,

This can be of interest to some:

- 
https://securityintelligence.com/posts/top-five-security-focus-areas-for-mainframes/
- https://www.ibm.com/downloads/cas/A9NKZ8WE

Any thoughts/comments?


Thanks,
Filip

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

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

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

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

Re: Mainframes testing

[Charles Mills]

I disagree somewhat with the other two commenters.

The papers are NOT an advanced how-to for RACF administrators! (For that, see 
the DISA STIGs!) But they are a decent intro for a manager who is ignorant of 
-- and frankly, need not be concerned with -- configuration details. They 
weren't written for readers of this list -- but think about your manager or his 
boss ...

The first paper is pretty good IMHO. Would anyone disagree that the five 
vulnerabilities listed are at least among the top ten or so vulnerabilities?

The second paper is certainly airline magazine level. Yeah, the quote cited by 
Lennie makes absolutely no sense. But there are some good points in there. 
Would anyone disagree with the following? Would anyone say it would NOT be good 
if every CIO at a mainframe organization read the following?

The mainframe
was and is critical to commercial databases, transaction
servers and applications that require high reliability,
scalability, compatibility and speed. In fact, mainframes
handle 30 billion business transactions every single day—
and that number is only expected to grow1.
However, companies face challenges ensuring their mainframes
are secure. With IT resources stretched and criminal attacks
on the rise, CIOs and CISOs need to make sure their mainframes
are locked down.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Filip Palian
Sent: Monday, August 12, 2019 6:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Mainframes testing

Hey List,

This can be of interest to some:

- 
https://securityintelligence.com/posts/top-five-security-focus-areas-for-mainframes/
- https://www.ibm.com/downloads/cas/A9NKZ8WE

Any thoughts/comments?

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

Re: Instruction speeds

[Charles Mills]

I second everything Chris Blaicher says. You just cannot say how long an 
instruction takes. Let me give you an example. (The example is based on 
theoretical concepts and has not been tested or benchmarked.)

Let's say you had some tight loop that was executed many thousands or millions 
of times. Let's say you were to insert into the code somewhere the following 
instruction: L R0,=F'1', and let's assume that R0 is not in use at that point 
so this addition does not change the logic of the program.

If the insertion were between some compare and an immediately following 
conditional jump or branch, and the literal pool were already in the data 
cache, then the impact of the added instruction might literally be zero. The 
processor could execute it entirely while it was waiting for the condition code 
to "settle" anyway. You might in a benchmark see absolutely no discernible 
change. So it would be fair to say that the LOAD took no time at all.

On the other hand if you inserted it at some other point in the code, where the 
literal pool was not in the cache already, or worse, was always at that point 
in the flow cached for write access on some other processor, then the impact 
might be quite noticeable (assuming enough executions of the loop -- on a human 
scale of time, ANY instruction takes no noticeable time at all).

With regard to your specific questions, I think of a L/ST sequence as being 
faster than an MVC for four aligned bytes, but I am not certain that is true. 
(MUCH faster? I seriously doubt it.) Other factors such as those discussed in 
my little example above are much more significant.

I am told that LA is "worse" than other "increment" instructions because it 
involves an index register. The instruction to use to increment a register is 
undoubtedly AHI for reasons that I believe Chris mentions. AH (or A) is 
certainly the worst of the lot because it involves storage access.

My (admittedly grossly oversimplified) rule of thumb when coding is 
"instructions take no time at all; memory accesses take forever."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Monday, August 12, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume
that executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
WORD.

Or does this really matter as much as ordering the instructions so they are
optimized for the pipeline?

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

Re: Instruction speeds

[Brian Chapman]

Thanks everyone for your input. I learned a lot from these responses. I
actually meant to write ADD HALFWORD IMMEDIATE in my original email. I was
surprised to hear about LA. I had assumed that direct register manipulation
was the fastest.

On the topic of cache, how do I know that my literal pool is actively
cached at execution of a certain instruction? What would cause the hardware
to move my literal pool out of cache?


Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 10:17 AM Charles Mills  wrote:

> I second everything Chris Blaicher says. You just cannot say how long an
> instruction takes. Let me give you an example. (The example is based on
> theoretical concepts and has not been tested or benchmarked.)
>
> Let's say you had some tight loop that was executed many thousands or
> millions of times. Let's say you were to insert into the code somewhere the
> following instruction: L R0,=F'1', and let's assume that R0 is not in use
> at that point so this addition does not change the logic of the program.
>
> If the insertion were between some compare and an immediately following
> conditional jump or branch, and the literal pool were already in the data
> cache, then the impact of the added instruction might literally be zero.
> The processor could execute it entirely while it was waiting for the
> condition code to "settle" anyway. You might in a benchmark see absolutely
> no discernible change. So it would be fair to say that the LOAD took no
> time at all.
>
> On the other hand if you inserted it at some other point in the code,
> where the literal pool was not in the cache already, or worse, was always
> at that point in the flow cached for write access on some other processor,
> then the impact might be quite noticeable (assuming enough executions of
> the loop -- on a human scale of time, ANY instruction takes no noticeable
> time at all).
>
> With regard to your specific questions, I think of a L/ST sequence as
> being faster than an MVC for four aligned bytes, but I am not certain that
> is true. (MUCH faster? I seriously doubt it.) Other factors such as those
> discussed in my little example above are much more significant.
>
> I am told that LA is "worse" than other "increment" instructions because
> it involves an index register. The instruction to use to increment a
> register is undoubtedly AHI for reasons that I believe Chris mentions. AH
> (or A) is certainly the worst of the lot because it involves storage access.
>
> My (admittedly grossly oversimplified) rule of thumb when coding is
> "instructions take no time at all; memory accesses take forever."
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Chapman
> Sent: Monday, August 12, 2019 5:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Instruction speeds
>
> Hi everyone,
>
> I did some searching, but I didn't find anything that really discussed this
> on the topic that I'm interested. Is there anything published that compares
> the cycle times of the most used instructions?
>
> For example; moving an address between areas of storage. I would assume
> that executing a LOAD and STORE would be much quicker than executing a MVC.
>
> Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
> WORD.
>
> Or does this really matter as much as ordering the instructions so they are
> optimized for the pipeline?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Instruction speeds

[Giliad Wilf]

On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman  wrote:

>Hi everyone,
>
>I did some searching, but I didn't find anything that really discussed this
>on the topic that I'm interested. Is there anything published that compares
>the cycle times of the most used instructions?
>
>For example; moving an address between areas of storage. I would assume
>that executing a LOAD and STORE would be much quicker than executing a MVC.
>
>Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
>WORD.
>
>Or does this really matter as much as ordering the instructions so they are
>optimized for the pipeline?
>

There used to be, with every new IBM System/360 machine, a "Functional 
Characteristics" publication stating "Instruction Times" in microseconds.
Here is one for the IBM System/360 Model 85:

http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf

See page 27.

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

WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[esmie moo]

Gentle Readers,
Is there a way of weeding out dsns with cataloged entries only.  I tried DFDSS 
logical backup with NORUN option but it did not give me the desired results.  I 
coded the VOLSER of the disk to no avail.  I am doing this exercise in 
preparation of removing old dasd but experiences of the past jobs failed 
because the dsn is not accessible
Any suggestions would be helpful and welcomed.Here is an example of my jcl:
//NORUN   EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'          //*DFDSS1  
 EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440                  //DASD1    DD 
UNIT=SYSALLDA,VOL=SER=PROD91,DISP=SHR                  //TAPE1  DD 
DSN=SYS2.CLOGR1.CLOGR2.LOGICAL,DISP=(,CATLG,DELETE),     //             
UNIT=3490,TRTCH=COMP,LABEL=(1,SL)                     //SYSPRINT DD  SYSOUT=*   
                                           //SYSMAP   DD SYSOUT=*               
                                //SYSIN    DD  *                                
                       DUMP DATASET(INCLUDE(SYS2.ORDMS.FILES.PROD))  -          
                SPHERE                                       -                  
     SELECTMULTI(FIRST)                           -                       
LOGINDDNAME(DASD1)                          -                        
OUTDD(TAPE1) OPT(4) ALLDATA(*) ALLEXCP -                             TOL(ENQF)  
                                                    /*                          
                                         

 

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

[SUSPECTED SPAM] Re: Instruction speeds

[Mike Shaw]

On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
..> 
JUMPs are faster than BRANCHes.

.


I don't know what you mean by that Chris.

The various types of Jump instructions are just extended mnemonics for 
various types of Branch instructions. JNE generates the same machine 
instruction as BNE, etc.


Do you mean the combined compare and jump instructions like CLGRJ?

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

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

Re: NTP Server connectivity quandary

[Dana Mitchell]

Ok, just for grins, lets try this:

Go into 'Single Object Operations' for the CPC in question.   Console Actions 
-> Network Diagnostic Information ->  Ping tab.  PING the address of the HMC 
you were trying to use as the sysplex time NTP Time Server.  See if that SE can 
successfully ping that hmc interface.

Dana

On Tue, 13 Aug 2019 12:34:03 +, Mark Jacobs  
wrote:

>Yes. We have STP.
>
>It's currently unconfigured. I'm waiting until I get NTP services setup before 
>I setup the CTN.
>

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

Re: Instruction speeds

[Brian Chapman]

Thanks Giliad. This is what I was searching for. I understand that the
timings in this document are very old and probably wildly inaccurate for
today's Z systems, but would it be on a relative scale? Would a LR be twice
the speed of a L?



Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 10:28 AM Giliad Wilf <
00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman 
> wrote:
>
> >Hi everyone,
> >
> >I did some searching, but I didn't find anything that really discussed
> this
> >on the topic that I'm interested. Is there anything published that
> compares
> >the cycle times of the most used instructions?
> >
> >For example; moving an address between areas of storage. I would assume
> >that executing a LOAD and STORE would be much quicker than executing a
> MVC.
> >
> >Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
> >WORD.
> >
> >Or does this really matter as much as ordering the instructions so they
> are
> >optimized for the pipeline?
> >
>
> There used to be, with every new IBM System/360 machine, a "Functional
> Characteristics" publication stating "Instruction Times" in microseconds.
> Here is one for the IBM System/360 Model 85:
>
>
> http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf
>
> See page 27.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: NTP Server connectivity quandary

[Mark Jacobs]

Never saw this error before.

Command failed, exit value is 2.
The command was [ping 10.2.8.62 -s 100 -c 5 -w 10]

There is something wonky going on here.

Thanks for the idea.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, August 13, 2019 10:47 AM, Dana Mitchell  wrote:

> Ok, just for grins, lets try this:
>
> Go into 'Single Object Operations' for the CPC in question. Console Actions 
> -> Network Diagnostic Information -> Ping tab. PING the address of the HMC 
> you were trying to use as the sysplex time NTP Time Server. See if that SE 
> can successfully ping that hmc interface.
>
> Dana
>
> On Tue, 13 Aug 2019 12:34:03 +, Mark Jacobs markjac...@protonmail.com 
> wrote:
>
> > Yes. We have STP.
> > It's currently unconfigured. I'm waiting until I get NTP services setup 
> > before I setup the CTN.
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: [SUSPECTED SPAM] Re: Instruction speeds

[Brian Chapman]

Mike,

I believe the difference is related to the fact that branch instructions
require a base register and jump does not.



Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 10:40 AM Mike Shaw  wrote:

> On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
> > ..>
> > JUMPs are faster than BRANCHes.
> > .
>
> I don't know what you mean by that Chris.
>
> The various types of Jump instructions are just extended mnemonics for
> various types of Branch instructions. JNE generates the same machine
> instruction as BNE, etc.
>
> Do you mean the combined compare and jump instructions like CLGRJ?
>
> Mike Shaw
> MVS/QuickRef Support Group
> Chicago-Soft, Ltd.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[John McKown]

On Tue, Aug 13, 2019 at 9:37 AM esmie moo <
012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:

> Gentle Readers,
> Is there a way of weeding out dsns with cataloged entries only.  I tried
> DFDSS logical backup with NORUN option but it did not give me the desired
> results.  I coded the VOLSER of the disk to no avail.  I am doing this
> exercise in preparation of removing old dasd but experiences of the past
> jobs failed because the dsn is not accessible
> Any suggestions would be helpful and welcomed.Here is an example of my jcl:
> //NORUN   EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
>   //*DFDSS1   EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440
>   //DASD1DD UNIT=SYSALLDA,VOL=SER=PROD91,DISP=SHR
>   //TAPE1  DD DSN=SYS2.CLOGR1.CLOGR2.LOGICAL,DISP=(,CATLG,DELETE), //
>UNIT=3490,TRTCH=COMP,LABEL=(1,SL) //SYSPRINT
> DD  SYSOUT=*  //SYSMAP   DD
> SYSOUT=*   //SYSINDD  *
>DUMP
> DATASET(INCLUDE(SYS2.ORDMS.FILES.PROD))  -  SPHERE
>  -
> SELECTMULTI(FIRST)   -
> LOGINDDNAME(DASD1)  -
> OUTDD(TAPE1) OPT(4) ALLDATA(*) ALLEXCP -
> TOL(ENQF)  /*
>
>
>
Do you mean DSNs in a catalog that don't exist on some volume (I am
guessing DASD in particular)? ADRDSSU won't address that. T-REX has a SCRUB
command which will do it. We use that at disaster recovery. I am not aware
of any z/OS "built in" facility to do that.

-- 
A sine curve goes off to infinity, or at least the end of the blackboard.
-- Prof. Steiner

Maranatha! <><
John McKown

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[ITschak Mugzach]

If I recall correctly, the VTOC command (CBT) has an option to list
datasets catalog status. Using volume masking you can achive need needs.

ITschak

On Tue, Aug 13, 2019 at 6:01 PM John McKown 
wrote:

> On Tue, Aug 13, 2019 at 9:37 AM esmie moo <
> 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Gentle Readers,
> > Is there a way of weeding out dsns with cataloged entries only.  I tried
> > DFDSS logical backup with NORUN option but it did not give me the desired
> > results.  I coded the VOLSER of the disk to no avail.  I am doing this
> > exercise in preparation of removing old dasd but experiences of the past
> > jobs failed because the dsn is not accessible
> > Any suggestions would be helpful and welcomed.Here is an example of my
> jcl:
> > //NORUN   EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
> >   //*DFDSS1   EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440
> >   //DASD1DD UNIT=SYSALLDA,VOL=SER=PROD91,DISP=SHR
> >   //TAPE1  DD DSN=SYS2.CLOGR1.CLOGR2.LOGICAL,DISP=(,CATLG,DELETE), //
> >UNIT=3490,TRTCH=COMP,LABEL=(1,SL)
>  //SYSPRINT
> > DD  SYSOUT=*  //SYSMAP   DD
> > SYSOUT=*   //SYSINDD  *
> >DUMP
> > DATASET(INCLUDE(SYS2.ORDMS.FILES.PROD))  -
> SPHERE
> >  -
> > SELECTMULTI(FIRST)   -
> > LOGINDDNAME(DASD1)  -
> > OUTDD(TAPE1) OPT(4) ALLDATA(*) ALLEXCP -
> > TOL(ENQF)  /*
> >
> >
> >
> Do you mean DSNs in a catalog that don't exist on some volume (I am
> guessing DASD in particular)? ADRDSSU won't address that. T-REX has a SCRUB
> command which will do it. We use that at disaster recovery. I am not aware
> of any z/OS "built in" facility to do that.
>
> --
> A sine curve goes off to infinity, or at least the end of the blackboard.
> -- Prof. Steiner
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: Instruction speeds

[Charles Mills]

Noo

That was what I was trying to say: you can no longer say "instruction X takes n 
cycles." You just cannot. That is why IBM no longer publishes such a thing. At 
best case an LR or an L take "no time at all" -- read what I wrote earlier. 
Worst case an LR takes a little while and an L takes a really long time. (How's 
that for technical precision?)

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Tuesday, August 13, 2019 7:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Thanks Giliad. This is what I was searching for. I understand that the
timings in this document are very old and probably wildly inaccurate for
today's Z systems, but would it be on a relative scale? Would a LR be twice
the speed of a L?



Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 10:28 AM Giliad Wilf <
00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman 
> wrote:
>
> >Hi everyone,
> >
> >I did some searching, but I didn't find anything that really discussed
> this
> >on the topic that I'm interested. Is there anything published that
> compares
> >the cycle times of the most used instructions?
> >
> >For example; moving an address between areas of storage. I would assume
> >that executing a LOAD and STORE would be much quicker than executing a
> MVC.
> >
> >Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
> >WORD.
> >
> >Or does this really matter as much as ordering the instructions so they
> are
> >optimized for the pipeline?
> >
>
> There used to be, with every new IBM System/360 machine, a "Functional
> Characteristics" publication stating "Instruction Times" in microseconds.
> Here is one for the IBM System/360 Model 85:
>
>
> http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf
>
> See page 27.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[Rick J. Valles]

This is what we use (from my friend, John C. Miller @ jmit.com 
):


//S1  EXEC PGM=ADRDSSU,PARM='TYPRUN=NORUN'
//SYSPRINT DD  SYSOUT=*
//TAPE DD  DUMMY
//SYSINDD  *
 DUMP DS(INC(**) BY(CATLG EQ NO)) OUTDD(TAPE) LOGINDYNAM(SYC500)


r

> On Aug 13, 2019, at 9:00 AM, John McKown  wrote:
> 
> On Tue, Aug 13, 2019 at 9:37 AM esmie moo <
> 012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> Gentle Readers,
>> Is there a way of weeding out dsns with cataloged entries only.  I tried
>> DFDSS logical backup with NORUN option but it did not give me the desired
>> results.  I coded the VOLSER of the disk to no avail.  I am doing this
>> exercise in preparation of removing old dasd but experiences of the past
>> jobs failed because the dsn is not accessible
>> Any suggestions would be helpful and welcomed.Here is an example of my jcl:
>> //NORUN   EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
>>  //*DFDSS1   EXEC PGM=ADRDSSU,REGION=4096K,TIME=1440
>>  //DASD1DD UNIT=SYSALLDA,VOL=SER=PROD91,DISP=SHR
>>  //TAPE1  DD DSN=SYS2.CLOGR1.CLOGR2.LOGICAL,DISP=(,CATLG,DELETE), //
>>   UNIT=3490,TRTCH=COMP,LABEL=(1,SL) //SYSPRINT
>> DD  SYSOUT=*  //SYSMAP   DD
>> SYSOUT=*   //SYSINDD  *
>>   DUMP
>> DATASET(INCLUDE(SYS2.ORDMS.FILES.PROD))  -  SPHERE
>> -
>> SELECTMULTI(FIRST)   -
>> LOGINDDNAME(DASD1)  -
>> OUTDD(TAPE1) OPT(4) ALLDATA(*) ALLEXCP -
>> TOL(ENQF)  /*
>> 
>> 
>> 
> Do you mean DSNs in a catalog that don't exist on some volume (I am
> guessing DASD in particular)? ADRDSSU won't address that. T-REX has a SCRUB
> command which will do it. We use that at disaster recovery. I am not aware
> of any z/OS "built in" facility to do that.
> 
> -- 
> A sine curve goes off to infinity, or at least the end of the blackboard.
> -- Prof. Steiner
> 
> Maranatha! <><
> John McKown
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: Instruction speeds

[Giliad Wilf]

Hi Brian,

I did not see this sort of publications for three or four decades.

Maybe IBM zServer engineers still use some instruction timing charts during 
chip design/development.

As far as I'm concerned, my emphasis while coding is on clarity and 
readability. 

Regards,
 
On Tue, 13 Aug 2019 10:52:05 -0400, Brian Chapman  wrote:

>Thanks Giliad. This is what I was searching for. I understand that the
>timings in this document are very old and probably wildly inaccurate for
>today's Z systems, but would it be on a relative scale? Would a LR be twice
>the speed of a L?
>
>
>
>Thank you,
>
>Brian Chapman
>
>
>On Tue, Aug 13, 2019 at 10:28 AM Giliad Wilf <
>00d50942efa9-dmarc-requ...@listserv.ua.edu> wrote:
>
>> On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman 
>> wrote:
>>
>> >Hi everyone,
>> >
>> >I did some searching, but I didn't find anything that really discussed
>> this
>> >on the topic that I'm interested. Is there anything published that
>> compares
>> >the cycle times of the most used instructions?
>> >
>> >For example; moving an address between areas of storage. I would assume
>> >that executing a LOAD and STORE would be much quicker than executing a
>> MVC.
>> >
>> >Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
>> >WORD.
>> >
>> >Or does this really matter as much as ordering the instructions so they
>> are
>> >optimized for the pipeline?
>> >
>>
>> There used to be, with every new IBM System/360 machine, a "Functional
>> Characteristics" publication stating "Instruction Times" in microseconds.
>> Here is one for the IBM System/360 Model 85:
>>
>>
>> http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf
>>
>> See page 27.
>>

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

Re: Instruction speeds

[Charles Mills]

> how do I know that my literal pool is actively
> cached at execution of a certain instruction?

Short answer: you cannot.

Long answer: Keep your data in a 256-byte-aligned area separate from your 
instructions. If you are really fussy, separate read-only from read/write data 
in separate 256-byte-aligned areas. Separate into another area any data that is 
modified by one task and read or written by another. This will give you a 
fighting chance that your data will be in cache. If my hypothetical L R0,=F'1' 
were shortly preceded by L R2,=F'2' then there is a good chance that the F'1' 
will already be in cache when you get to the L R0. (A good example but poor 
coding practice! Use LHI R0,1 not L R0,=F'1' and avoid data cache issues 
altogether.)

Really long answer: The hardware keeps track. There is a set of counters for 
cache hits and misses of various types. The counters are model-dependent. Take 
a look at SMF 113 and go from there. (Products like Omegamon and MainView may 
have the ability to report on the counters -- I don't know.) 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Tuesday, August 13, 2019 7:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Thanks everyone for your input. I learned a lot from these responses. I
actually meant to write ADD HALFWORD IMMEDIATE in my original email. I was
surprised to hear about LA. I had assumed that direct register manipulation
was the fastest.

On the topic of cache, how do I know that my literal pool is actively
cached at execution of a certain instruction? What would cause the hardware
to move my literal pool out of cache?

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

Re: Instruction speeds

[Charles Mills]

+1

Hardware is cheap. Programmers (and bugs!) are expensive.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Giliad Wilf
Sent: Tuesday, August 13, 2019 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Hi Brian,

I did not see this sort of publications for three or four decades.

Maybe IBM zServer engineers still use some instruction timing charts during 
chip design/development.

As far as I'm concerned, my emphasis while coding is on clarity and 
readability. 

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

Re: Instruction speeds

[Steve Smith]

Write good code and forget about instruction timings.  With any luck your
code will have to perform on several generations of architecture and
machines.

There's a big difference between B- (base-index-displacement) branches and
J- (or BR-) (relative address) instructions.  Surely by now, this should go
without saying.  Regardless of whether they're "faster" or not, they are
much better, and as that is well-documented, I won't belabor it.

sas

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

Re: Instruction speeds

[Charles Mills]

A GREAT introduction to this topic, by someone who unlike me actually knows 
what he is talking about:

https://linuxmain.blogspot.com/2017/02/zoptimizationprimer.html 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Monday, August 12, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume
that executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
WORD.

Or does this really matter as much as ordering the instructions so they are
optimized for the pipeline?

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

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

Re: [SUSPECTED SPAM] Re: Instruction speeds

[Charles Mills]

> JNE generates the same machine instruction as BNE, etc.

Not really. The (old) branch instructions like BNE use a base register and a 
<4K displacement. The Jxx opcodes are synonyms for (new -- as in 20+ years) 
relative branch instructions which use a +/-64K relative displacement. 

The jumps are potentially faster because the processor never has to worry about 
whether the base register was changed a couple of instructions back. It always 
knows where the instruction counter is.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Shaw
Sent: Tuesday, August 13, 2019 7:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [SUSPECTED SPAM] Re: Instruction speeds

On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
> ..> 
> JUMPs are faster than BRANCHes.
> .

I don't know what you mean by that Chris.

The various types of Jump instructions are just extended mnemonics for 
various types of Branch instructions. JNE generates the same machine 
instruction as BNE, etc.

Do you mean the combined compare and jump instructions like CLGRJ?

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

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

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

[SUSPECTED SPAM] Re: [SUSPECTED SPAM] Re: Instruction speeds

[Gord Tomlin]

On 2019-08-13 10:33, Mike Shaw wrote:

JNE generates the same machine instruction as BNE, etc.


Nope.

Are you possibly fooling yourself by looking at code that uses IEABRC or 
IEABRCX?


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: Instruction speeds

[Brian Chapman]

Thanks Charles and Steve.

Now that I am becoming a more experience assembler programmer, I have
wondered if I should be greatly concerned about instruction timings or
pipeline order, or just simply focus on readability and maintenance.
Especially since assembler programming is becoming a dying art. I think I
am only 1 of a handful of assembler programmers at my shop with hundreds of
mainframe programmers! I think you both answered my question. Thanks!



Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 11:39 AM Steve Smith  wrote:

> Write good code and forget about instruction timings.  With any luck your
> code will have to perform on several generations of architecture and
> machines.
>
> There's a big difference between B- (base-index-displacement) branches and
> J- (or BR-) (relative address) instructions.  Surely by now, this should go
> without saying.  Regardless of whether they're "faster" or not, they are
> much better, and as that is well-documented, I won't belabor it.
>
> sas
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Instruction speeds

[Rick J. Valles]

Here’s my IEFBR15 “Utility” - it’s pretty fast:

  Active Usings: None
  Loc  Object CodeAddr1 Addr2  Stmt   Source Statement
000 2 1 IEFBR15  CSECT
00 07FF   2  BR15
  3  END

:)


r

> On Aug 13, 2019, at 10:09 AM, Brian Chapman  wrote:
> 
> Thanks Charles and Steve.
> 
> Now that I am becoming a more experience assembler programmer, I have
> wondered if I should be greatly concerned about instruction timings or
> pipeline order, or just simply focus on readability and maintenance.
> Especially since assembler programming is becoming a dying art. I think I
> am only 1 of a handful of assembler programmers at my shop with hundreds of
> mainframe programmers! I think you both answered my question. Thanks!
> 
> 
> 
> Thank you,
> 
> Brian Chapman
> 
> 
> On Tue, Aug 13, 2019 at 11:39 AM Steve Smith  wrote:
> 
>> Write good code and forget about instruction timings.  With any luck your
>> code will have to perform on several generations of architecture and
>> machines.
>> 
>> There's a big difference between B- (base-index-displacement) branches and
>> J- (or BR-) (relative address) instructions.  Surely by now, this should go
>> without saying.  Regardless of whether they're "faster" or not, they are
>> much better, and as that is well-documented, I won't belabor it.
>> 
>> sas
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

Re: Instruction speeds

[Tony Harminc]

On Tue, 13 Aug 2019 at 11:39, Steve Smith  wrote:


> There's a big difference between B- (base-index-displacement) branches and
> J- (or BR-) (relative address) instructions.  Surely by now, this should go
> without saying.  Regardless of whether they're "faster" or not, they are
> much better, and as that is well-documented, I won't belabor it.
>

There is one way in which the relative branch instructions are "worse", not
at run time, but assembly time. Say you have a module with (generally good
practice) a bunch of small internal subroutines. Let's say SUBA to start:

SUBA   entry code
 USING SUBA,Rbase
 do SUBA's work
 LTR   R15,R15   Success?
 BZUPDATE_DATA_A
 deal with failure and return
UPDATE_DATA_A store some data related to A
 Return
 DROP Rbase

Now you want to add a routine to do work B. So you clone the SUBA code, and
then change all the labels.

SUBB   entry code
 USING SUBB,Rbase
 do SUBB's work
 LTR   R15,R15   Success?
 BZUPDATE_DATA_A
 deal with failure and return
UPDATE_DATA_B store some data related to B
 Return
 DROP Rbase

But - as I did above - you fail to change the branch to UPDATE_DATA_A to
UPDATE_DATA_B. With BZ you will have an addressibility error (or at least
with careful use of USING and DROP you can force one), but with JZ it will
almost certainly assemble without error. Then at run time you will branch
into the middle of the wrong routine.

I'm not aware of assembly time tools or options to avoid this. Really this
is a larger assembler issue where name scoping is required, but the
relative branch instructions have made it a much easier mistake to make.

Tony H.

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

Re: Instruction speeds

[John McKown]

On Tue, Aug 13, 2019 at 11:10 AM Brian Chapman  wrote:

> Thanks Charles and Steve.
>
> Now that I am becoming a more experience assembler programmer, I have
> wondered if I should be greatly concerned about instruction timings or
> pipeline order, or just simply focus on readability and maintenance.
> Especially since assembler programming is becoming a dying art. I think I
> am only 1 of a handful of assembler programmers at my shop with hundreds of
> mainframe programmers! I think you both answered my question. Thanks!
>

KISS - make it easy to maintain. I have written code which even I didn't
understand a few years later.


>
>
> Thank you,
>
> Brian Chapman
>
-- 
I find television very educational. The minute somebody turns it on, I go
into the library and read a good book
-- Groucho Marx

Maranatha! <><
John McKown

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

Re: Instruction speeds

[Jesse 1 Robinson]

My advice is always to make it easy for next guy. Chances are, over time, the 
'next guy' will be the future you. 

.
.
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 Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John McKown
Sent: Tuesday, August 13, 2019 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Instruction speeds

On Tue, Aug 13, 2019 at 11:10 AM Brian Chapman  wrote:

> Thanks Charles and Steve.
>
> Now that I am becoming a more experience assembler programmer, I have 
> wondered if I should be greatly concerned about instruction timings or 
> pipeline order, or just simply focus on readability and maintenance.
> Especially since assembler programming is becoming a dying art. I 
> think I am only 1 of a handful of assembler programmers at my shop 
> with hundreds of mainframe programmers! I think you both answered my 
> question. Thanks!
>

KISS - make it easy to maintain. I have written code which even I didn't 
understand a few years later.


>
>
> Thank you,
>
> Brian Chapman


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

Re: Instruction speeds

[Seymour J Metz]

The rules for assemblers are the same as the rules for any language processor:

  1. Correctness trumps speed

  2. Make it easier for somebody to figure out how it works and how to change 
it. Clever
 code is fine, but document it adequately.

  3. When you change platforms or change translators, that which was slow may 
be fast
 and that which was fast may be slow. Beware of optimizations that 
disappear when you
 upgrade or that impede maintenance.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Brian Chapman 
Sent: Tuesday, August 13, 2019 12:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Thanks Charles and Steve.

Now that I am becoming a more experience assembler programmer, I have
wondered if I should be greatly concerned about instruction timings or
pipeline order, or just simply focus on readability and maintenance.
Especially since assembler programming is becoming a dying art. I think I
am only 1 of a handful of assembler programmers at my shop with hundreds of
mainframe programmers! I think you both answered my question. Thanks!



Thank you,

Brian Chapman


On Tue, Aug 13, 2019 at 11:39 AM Steve Smith  wrote:

> Write good code and forget about instruction timings.  With any luck your
> code will have to perform on several generations of architecture and
> machines.
>
> There's a big difference between B- (base-index-displacement) branches and
> J- (or BR-) (relative address) instructions.  Surely by now, this should go
> without saying.  Regardless of whether they're "faster" or not, they are
> much better, and as that is well-documented, I won't belabor it.
>
> sas
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: NTP Server connectivity quandary

[Dana Mitchell]

On Tue, 13 Aug 2019 14:54:02 +, Mark Jacobs  
wrote:

>Never saw this error before.
>
>Command failed, exit value is 2.
>The command was [ping 10.2.8.62 -s 100 -c 5 -w 10]
>
>There is something wonky going on here.
>


Thats the message I receive if I try to ping a completely bogus address.   
something sounds amiss with your network setup of the SE->HMC connections

Dana

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

Re: Instruction speeds

[Pew, Curtis G]

On Aug 13, 2019, at 11:26 AM, Jesse 1 Robinson  wrote:
> 
> My advice is always to make it easy for next guy. Chances are, over time, the 
> 'next guy' will be the future you. 

Amen. The advice I give (I got it from Eric S. Raymond) is “Always write code 
as if the next person who will maintain it is a homicidal maniac who knows 
where you live.”

-- 
Pew, Curtis G
curtis@austin.utexas.edu






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

Re: Instruction speeds

[Seymour J Metz]

It's almost impossible to compare timings between processors except in the 
context of a well defined benchmark; run a different benchmark and you get a 
different answer. A classic example is comparing a 370/158 to a 4341; use 
packed decimal heavily and you get one answer; use floating point heavily and 
you get the opposite answer.

IBM used to publish instruction timings, and with every new model the rules got 
more complicated. The last one that I saw was for the 370/168, and it was full 
of special cases. I suspect that an instruction timing manual for, e.g., a z14, 
would be bigger than PoOps, and not terribly useful even if you were certain 
that the code would only run on that model.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Brian Chapman 
Sent: Monday, August 12, 2019 8:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume
that executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
WORD.

Or does this really matter as much as ordering the instructions so they are
optimized for the pipeline?

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

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

Re: [SUSPECTED SPAM] Re: Instruction speeds

[Seymour J Metz]

Not only no but hell no.

JNE foo generates A74 with a mask of F, the same code as BRC 15,foo; BNE foo 
generates 47 with a mask of F, the same code as BC 15,foo.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Mike Shaw 
Sent: Tuesday, August 13, 2019 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [SUSPECTED SPAM] Re: Instruction speeds

On 8/12/2019 9:33 PM, Christopher Y. Blaicher wrote:
> ..>
> JUMPs are faster than BRANCHes.
> .

I don't know what you mean by that Chris.

The various types of Jump instructions are just extended mnemonics for
various types of Branch instructions. JNE generates the same machine
instruction as BNE, etc.

Do you mean the combined compare and jump instructions like CLGRJ?

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

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

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

Re: Instruction speeds

[Seymour J Metz]

Avoid processor-specific optimizations; what is millicode on one box may not be 
on another. Worry first about getting your code correct and maintainable.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Christopher Y. Blaicher 
Sent: Monday, August 12, 2019 9:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

There is no instruction cycle time table.  There are some general guidelines 
you can follow.

Don't overload cache.  Locality of reference for instructions and data is 
important.

The machine will do out-of-order instruction processing, but there are limits.  
If you load a register don't use it as a base register in the next instruction, 
if you can help it.

MVC is a lot faster than MVCL.  A series of MVC's will beat a MVCL up to about 
32K.

JUMPs are faster than BRANCHes.

Don’t use instructions that set the condition code, unless you need it.

Millicode instructions have startup and shutdown overheads.  Many times you can 
go faster using open code to do what a millicode instruction does.

Here is one that has nothing to do with an instruction - Don't assign CPs from 
different drawers to an LPAR, that includes ZIIPs.  Task switching across 
drawers kills cache and kills performance.  You will lose hundreds, if not 
thousands, of cycles.

There are some articles on the net that go over processor design and cache 
design.  The processor designs will give you a hint to the number of stages an 
instruction goes through.  Pipeline delays are what you try to avoid.

Chris Blaicher
Technical Architect
Syncsort, Inc.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Monday, August 12, 2019 8:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this on 
the topic that I'm interested. Is there anything published that compares the 
cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume that 
executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF WORD.

Or does this really matter as much as ordering the instructions so they are 
optimized for the pipeline?

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

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

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

Re: Instruction speeds

[Christopher Y. Blaicher]

Sorry, but 360 timings have no relevance to today's systems.  Out-of-order 
processing, executing up to 6 instructions concurrently and a myriad of other 
factors make accurate timings impossible.

Cache utilization is one of the biggest factors. Processing more data than the 
L1 and L2 caches can hold will really mess things up.  Most people don't have 
to worry about that, unless you have large tables in memory that you access a 
lot, especially randomly.

Chris Blaicher
Technical Architect
Syncsort, Inc.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Giliad Wilf
Sent: Tuesday, August 13, 2019 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman  wrote:

>Hi everyone,
>
>I did some searching, but I didn't find anything that really discussed 
>this on the topic that I'm interested. Is there anything published that 
>compares the cycle times of the most used instructions?
>
>For example; moving an address between areas of storage. I would assume 
>that executing a LOAD and STORE would be much quicker than executing a MVC.
>
>Or executing a LOAD ADDRESS to increment a register instead of ADD HALF 
>WORD.
>
>Or does this really matter as much as ordering the instructions so they 
>are optimized for the pipeline?
>

There used to be, with every new IBM System/360 machine, a "Functional 
Characteristics" publication stating "Instruction Times" in microseconds.
Here is one for the IBM System/360 Model 85:

http://www.bitsavers.org/pdf/ibm/360/funcChar/A22-6916-1_360-85_funcChar_Jun68.pdf

See page 27.

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

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

Re: Instruction speeds

[Tony Harminc]

If you are interested in how these things work under the covers (regardless
of whether it is possible or useful to minutely optimize your code these
days), you might check out any of the several presentations done at SHARE
and other places by Bob Rogers, now retired from IBM, under titles like
"How do you do what you do when you're an xxx CPU". The only one I can find
right now is for the z13, and it concentrates on the then-new SIMD
implementation, but nonetheless has a bunch on more general pipelining and
out of order execution.
https://share.confex.com/share/125/webprogram/Handout/Session17797/How%20do%20you%20do%20what%20you%20do%20when%20youre%20a%20z13%20CPU.pdf

Tony H.

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

Re: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY

[retired mainframer]

I think you are looking for the DIAGNOSE command found in the AMS manual.  It 
will compare the BCS and VVDS and identify mismatches in either direction.

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of esmie moo
> Sent: Tuesday, August 13, 2019 7:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: WEEDING OUT DSNS WITH CATALOG ENTRIES ONLY
> 
> Gentle Readers,
> Is there a way of weeding out dsns with cataloged entries only.  I tried 
> DFDSS logical
> backup with NORUN option but it did not give me the desired results.  I coded 
> the
> VOLSER of the disk to no avail.  I am doing this exercise in preparation of 
> removing
> old dasd but experiences of the past jobs failed because the dsn is not 
> accessible
> Any suggestions would be helpful and welcomed.Here is an example of my jcl:
> //NORUN   EXEC
> PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'  //*DFDSS1   E
> XEC PGM=ADRDSSU,REGION=4096K,TIME=1440  //DASD1DD
> UNIT=SYSALLDA,VOL=SER=PROD91,DISP=SHR  //TAPE1  DD
> DSN=SYS2.CLOGR1.CLOGR2.LOGICAL,DISP=(,CATLG,DELETE), // U
> NIT=3490,TRTCH=COMP,LABEL=(1,SL) //SYSPRINT
> DD  SYSOUT=*  //SYSMAP   DD
> SYSOUT=*   //SYSINDD  *
>DUMP DATASET(INCLUDE(SYS2.ORDMS.FILES.PROD))  -
>   SPHERE   -
>SELECTMULTI(FIRST)   -
>LOGINDDNAME(DASD1)  -
> OUTDD(TAPE1) OPT(4) ALLDATA(*) ALLEXCP -
>  TOL(ENQF)
>   /*
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Mainframes testing

[Seymour J Metz]

Item 3: Overprivileged Users

Some shops do not allow multiple userids for a single user but do have users 
wearing multiple hats. That essentially force the user to do work with a userid 
that has more privileges than he need for the specific shop.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Filip Palian 
Sent: Monday, August 12, 2019 9:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Mainframes testing

Hey List,

This can be of interest to some:

- 
https://secure-web.cisco.com/1OIsiVM7zhM_O0aZQcuTtuVgV3kySeCuzqadGzRG7TGbcvRzp_ZiMhZWW4QfH36no3CBMB1OTE_NS5Ipi0fsRX5zzpBxqU-cnS1_zRL8N4sAMdOsEHlTIT3EKVWWfPfgnt4p_-X5LkNlaQOPIV_aXI9Jt9ssvUpc8hF-WhuEqW90CmirzvBoGxkS2L5cR3Lkh1jHmXaBQpc-iX2OLOkIdduuTTDTwz8eavyH9QSImMckVx6EOVyyK9vRrGQuJiedWu6LVJzVR5v6MDYKfZfSQYwLXx3neRw5K6_YxnP7pWGZFAK-znaJAPh1mLpGuUgbv592iW6P_IJ_V-a2hhseUHDABg-P6NOIGpnlaIGdgCO29-J1o1CABd7EDAD4EvOrE-_3KKvwqiEuhMyCPyzevIUOixA4EIwkGP0FbdSotXMMNylxS_hnSHXkgKQzWk0NF/https%3A%2F%2Fsecurityintelligence.com%2Fposts%2Ftop-five-security-focus-areas-for-mainframes%2F
- 
https://secure-web.cisco.com/1jkc25WbrcnQ7k-vLpgvFJbNF8Pdz76rF5P92WbzZJYW74nbRww-rbOHnHgl3gm7sGPxk8MZ_2aCDtCqkV7FKuFxKgz6S69n9IGMJQ3d_PziOk8p5R3_Vh47CcyZO7Vu8cyGCrQ6rRFicOG1DcOkMsBuZkzIUFg-Kpzf11aeNW5L2FlNXaL_HCqjzRVBF9V494bZiajkYPUpDTJfws-3hB05D5sZ6kVTpK6ZhA-xlWql_7-FDP8P-ND-qr2mRqzoJ5g-q9vAOHMpHtiO1s2A9Z6TOYnHZQ90WHx2IOWjpw_J131CJaDgkGlVlnTyiKOzvMNxb7IfvZ1mk0bPddd6KEaJRbOB27hbJzIw2LiixZ7Baf5Nm8Dyj2czj5JUROLJcllfN2NPhTU0hj2ylLP9KKf6g69wCABuFZ0YQi-iWRB_xCefnKKiynBlYzq-caGhP/https%3A%2F%2Fwww.ibm.com%2Fdownloads%2Fcas%2FA9NKZ8WE

Any thoughts/comments?


Thanks,
Filip

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

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

Re: Instruction speeds

[Seymour J Metz]

Even on a S/360 some of the timing formulae were pretty hairy, and it got worse 
on the S/370. I shuuder to think of the size of a timing manual for a 
contemporary processor.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Christopher Y. Blaicher 
Sent: Tuesday, August 13, 2019 1:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

Sorry, but 360 timings have no relevance to today's systems.  Out-of-order 
processing, executing up to 6 instructions concurrently and a myriad of other 
factors make accurate timings impossible.

Cache utilization is one of the biggest factors. Processing more data than the 
L1 and L2 caches can hold will really mess things up.  Most people don't have 
to worry about that, unless you have large tables in memory that you access a 
lot, especially randomly.

Chris Blaicher
Technical Architect
Syncsort, Inc.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Giliad Wilf
Sent: Tuesday, August 13, 2019 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Instruction speeds

On Mon, 12 Aug 2019 20:48:18 -0400, Brian Chapman  wrote:

>Hi everyone,
>
>I did some searching, but I didn't find anything that really discussed
>this on the topic that I'm interested. Is there anything published that
>compares the cycle times of the most used instructions?
>
>For example; moving an address between areas of storage. I would assume
>that executing a LOAD and STORE would be much quicker than executing a MVC.
>
>Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
>WORD.
>
>Or does this really matter as much as ordering the instructions so they
>are optimized for the pipeline?
>

There used to be, with every new IBM System/360 machine, a "Functional 
Characteristics" publication stating "Instruction Times" in microseconds.
Here is one for the IBM System/360 Model 85:

http://secure-web.cisco.com/19LNkGXX4Edz3NAluLE3GhjFTVP9_mLYBd22slvDhfvUbm2Jt5ekKOU--1Kz0QVMQx1ouoa_BpMetCCoJ4xdIyY4NzLIdk88VX53anaLQuobJ75avxCyDJy-kwo_H5lVCr_v9X1WR-vV1o1MIABDa_d-f-Df8HGhW8zIp74ofJjbGlLsCjMS5Mt2dfXQktNY6965-re-qUFXfAceAhav4eNGeEb4ZIldHWp6mxvcae4JG2AuTzf-1eTaqaS1vF5RRXD5ViUDbK07v8Z3bfmV0DbtaHqNWsLYgLxiTpvZlXKP75_Meq7ZXcIMEri_ZB6RPUip72u7G43rsdRwfV7SnWdsQoZBRaXNT6Y9JQEVdK0otoAc3Eiz-yqND-iCbOYOnQJnQAd0JLLPVugKCcyT-Deh4rov50L9tIPEncm1MSAm5R4utmPTYZW9sStO45i3m/http%3A%2F%2Fwww.bitsavers.org%2Fpdf%2Fibm%2F360%2FfuncChar%2FA22-6916-1_360-85_funcChar_Jun68.pdf

See page 27.

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

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

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

Re: ISPF Question - browsing variable length records

[Seymour J Metz]

> Why not?  The host should transmit characters counted by the RDW, then NULs 
> to the end
> of the field.  Characters typed over those NULs would be returned to the host 
> on Read
> Modified; the NULs ignored.

Yes, ignored, not transmitted to the host. There will be no way to know which 
null the user overtyped with a space.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, August 12, 2019 4:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF Question - browsing variable length records

On Mon, 12 Aug 2019 17:59:45 +, Seymour J Metz wrote:

>> It should be intuitive: add blanks by positioning the cursor at the end of 
>> the
>> line and pressing the spacebar.
>
>Be careful what you ask for; you might get it. At which point IBM will get 
>mobs armed with pitchforks and torches.
>
Future shock.  But nowadays most of them would be more used to the
similar behavior of the echoplex terminals on their desktops.

>What you are asking for might make sense on an echoplex terminal; it doesn't 
>make sense on a 3270 terminal or TN3270 session.
>
Why not?  The host should transmit characters counted by the RDW, then NULs to 
the end
of the field.  Characters typed over those NULs would be returned to the host 
on Read
Modified; the NULs ignored.  Very close to the behavior of the echoplex 
terminal.

>OTOH, it might be viable to enhance the 3270 data stream to include a 
>collapsing blank (significant null) that would be deleted by an insert but 
>otherwise treated as a space.
>
Already, some competitors' terminals and emulators make trailing blanks
collapsible and/or convert NULs followed by non-null characters to blanks
on Read Modified.  I wanted a pitchfork and torch.  (But I believe the
behavior was optional.)

And some silly history:

Circa MVS/370, Data Management ref. stated that the minimum count
supported in an RDW was 5, and SPF Edit obligingly padded any empty
line with a single blank.  Nowadays, z/OS Using Data Sets states the
minimum is 4.  ISPF Edit continues to pad empty lines.  I can assume
only that this supports users who need to Edit on z/OS and run on
MVS/370.

And any 8-character line was padded to 9 with a blank.  I know no
explanation for this;  I don't know that the behavior persists.

-- gil

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

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

Re: Mainframes testing

[Robert Longabaugh]

"The mainframe was and is critical to commercial databases, transaction..."

"The mainframe is critical to commercial databases, transaction..."
<=== FIXED IT

Bob Longabaugh
Broadcom
Storage Management

On Tue, Aug 13, 2019 at 10:26 AM Seymour J Metz  wrote:

> Item 3: Overprivileged Users
>
> Some shops do not allow multiple userids for a single user but do have
> users wearing multiple hats. That essentially force the user to do work
> with a userid that has more privileges than he need for the specific shop.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Filip Palian 
> Sent: Monday, August 12, 2019 9:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Mainframes testing
>
> Hey List,
>
> This can be of interest to some:
>
> -
> https://secure-web.cisco.com/1OIsiVM7zhM_O0aZQcuTtuVgV3kySeCuzqadGzRG7TGbcvRzp_ZiMhZWW4QfH36no3CBMB1OTE_NS5Ipi0fsRX5zzpBxqU-cnS1_zRL8N4sAMdOsEHlTIT3EKVWWfPfgnt4p_-X5LkNlaQOPIV_aXI9Jt9ssvUpc8hF-WhuEqW90CmirzvBoGxkS2L5cR3Lkh1jHmXaBQpc-iX2OLOkIdduuTTDTwz8eavyH9QSImMckVx6EOVyyK9vRrGQuJiedWu6LVJzVR5v6MDYKfZfSQYwLXx3neRw5K6_YxnP7pWGZFAK-znaJAPh1mLpGuUgbv592iW6P_IJ_V-a2hhseUHDABg-P6NOIGpnlaIGdgCO29-J1o1CABd7EDAD4EvOrE-_3KKvwqiEuhMyCPyzevIUOixA4EIwkGP0FbdSotXMMNylxS_hnSHXkgKQzWk0NF/https%3A%2F%2Fsecurityintelligence.com%2Fposts%2Ftop-five-security-focus-areas-for-mainframes%2F
> -
> https://secure-web.cisco.com/1jkc25WbrcnQ7k-vLpgvFJbNF8Pdz76rF5P92WbzZJYW74nbRww-rbOHnHgl3gm7sGPxk8MZ_2aCDtCqkV7FKuFxKgz6S69n9IGMJQ3d_PziOk8p5R3_Vh47CcyZO7Vu8cyGCrQ6rRFicOG1DcOkMsBuZkzIUFg-Kpzf11aeNW5L2FlNXaL_HCqjzRVBF9V494bZiajkYPUpDTJfws-3hB05D5sZ6kVTpK6ZhA-xlWql_7-FDP8P-ND-qr2mRqzoJ5g-q9vAOHMpHtiO1s2A9Z6TOYnHZQ90WHx2IOWjpw_J131CJaDgkGlVlnTyiKOzvMNxb7IfvZ1mk0bPddd6KEaJRbOB27hbJzIw2LiixZ7Baf5Nm8Dyj2czj5JUROLJcllfN2NPhTU0hj2ylLP9KKf6g69wCABuFZ0YQi-iWRB_xCefnKKiynBlYzq-caGhP/https%3A%2F%2Fwww.ibm.com%2Fdownloads%2Fcas%2FA9NKZ8WE
>
> Any thoughts/comments?
>
>
> Thanks,
> Filip
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: ISPF Question - browsing variable length records

[Paul Gilmartin]

On Tue, 13 Aug 2019 17:39:09 +, Seymour J Metz wrote:

>> Why not?  The host should transmit characters counted by the RDW, then NULs 
>> to the end
>> of the field.  Characters typed over those NULs would be returned to the 
>> host on Read
>> Modified; the NULs ignored.
>
>Yes, ignored, not transmitted to the host. There will be no way to know which 
>null the user overtyped with a space.
> 
Does it matter?

I accept that as a limitation of the 327x data stream design.  I've exploited it
at times to insert a character such as ';' at the end of a line when the cursor
is inconveniently far:

Tab to next line.
Back-arrow twice.
Type ';'
ENTER.  The ';' scoots to where I want it.

If blanks were treated by Edit as ordinary characters, even as 3270
does, that ';' would appear after the blanks.  If I didn't want that,
I shouldn't have inserted the blanks in the first place.

-- gil

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

Re: NTP Server connectivity quandary

[Mark Jacobs]

That's what I think too. I've asked HW support to check it out.

Mark Jacobs


Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Tuesday, August 13, 2019 12:39 PM, Dana Mitchell  wrote:

> On Tue, 13 Aug 2019 14:54:02 +, Mark Jacobs markjac...@protonmail.com 
> wrote:
>
> > Never saw this error before.
> > Command failed, exit value is 2.
> > The command was [ping 10.2.8.62 -s 100 -c 5 -w 10]
> > There is something wonky going on here.
>
> Thats the message I receive if I try to ping a completely bogus address. 
> something sounds amiss with your network setup of the SE->HMC connections
>
> Dana
>
> ---
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: ISPF Question - browsing variable length records

[Seymour J Metz]

> Does it matter?

Not if you don't care whether the text is in the right column in your previous 
request.

> I accept that as a limitation of the 327x data stream design.  I've exploited 
> it
>at times to insert a character such as ';' at the end of a line when the cursor
>is inconveniently far:

Which is precisely why users would be unhappy if IBM changed that behavior.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, August 13, 2019 2:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF Question - browsing variable length records

On Tue, 13 Aug 2019 17:39:09 +, Seymour J Metz wrote:

>> Why not?  The host should transmit characters counted by the RDW, then NULs 
>> to the end
>> of the field.  Characters typed over those NULs would be returned to the 
>> host on Read
>> Modified; the NULs ignored.
>
>Yes, ignored, not transmitted to the host. There will be no way to know which 
>null the user overtyped with a space.
>
Does it matter?

I accept that as a limitation of the 327x data stream design.  I've exploited it
at times to insert a character such as ';' at the end of a line when the cursor
is inconveniently far:

Tab to next line.
Back-arrow twice.
Type ';'
ENTER.  The ';' scoots to where I want it.

If blanks were treated by Edit as ordinary characters, even as 3270
does, that ';' would appear after the blanks.  If I didn't want that,
I shouldn't have inserted the blanks in the first place.

-- gil

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

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

Re: ISPF Question - browsing variable length records

[Paul Gilmartin]

On Tue, 13 Aug 2019 18:53:37 +, Seymour J Metz wrote:

>> Does it matter?
>
>Not if you don't care whether the text is in the right column in your previous 
>request.
>
When I care, I set NULLS OFF, or use the spacebar.  Usually it doesn't matter 
to me --
Rexx, C, shell script, ...

>> I accept that as a limitation of the 327x data stream design.  I've 
>> exploited it
>>at times to insert a character such as ';' at the end of a line when the 
>>cursor
>>is inconveniently far:
>
>Which is precisely why users would be unhappy if IBM changed that behavior.
>
Which is why I didn't suggest IBM change it, nor change the 3270 specification.

-- gil

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

Re: ISPF Question - browsing variable length records

[Seymour J Metz]

> When I care, I set NULLS OFF, or use the spacebar. 

That's the right answer to the wrong question. You were asking about the 
ability to insert a blank in the middle of a string of nulls.

> Which is why I didn't suggest IBM change it, nor change the 3270 
> specification.

You wrote "It should be intuitive: add blanks by positioning the cursor at the 
end of the line and pressing the spacebar." That would require a change in the 
3270 specifications.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, August 13, 2019 3:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ISPF Question - browsing variable length records

On Tue, 13 Aug 2019 18:53:37 +, Seymour J Metz wrote:

>> Does it matter?
>
>Not if you don't care whether the text is in the right column in your previous 
>request.
>
When I care, I set NULLS OFF, or use the spacebar.  Usually it doesn't matter 
to me --
Rexx, C, shell script, ...

>> I accept that as a limitation of the 327x data stream design.  I've 
>> exploited it
>>at times to insert a character such as ';' at the end of a line when the 
>>cursor
>>is inconveniently far:
>
>Which is precisely why users would be unhappy if IBM changed that behavior.
>
Which is why I didn't suggest IBM change it, nor change the 3270 specification.

-- gil

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

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

Re: ISPF Question - browsing variable length records

[Paul Gilmartin]

On Tue, 13 Aug 2019 19:55:19 +, Seymour J Metz wrote:

>> When I care, I set NULLS OFF, or use the spacebar. 
>
>That's the right answer to the wrong question. You were asking about the 
>ability to insert a blank in the middle of a string of nulls.
> 
No, I asked about adding a blank at the end of a line.

>> Which is why I didn't suggest IBM change it, nor change the 3270 
>> specification.
>
>You wrote "It should be intuitive: add blanks by positioning the cursor at the 
>end of the line and pressing the spacebar." That would require a change in the 
>3270 specifications.
>
No, if I do that now, Read Modified returns that blank to the host.  ISPF
Edit discards it.

-- gil

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

Re: Instruction speeds

[CM Poncelet]

FWIW
 
On the Hitachi Skyline bipolar mainframe (from 1995), the instruction
processor speeds were:
- RR: 3ns.
- SS: 6-10ns if L2 cached, else 60-80ns if data-fetched from central
storage.
 
On IBM's CMOS G4 mainframes:
- RR: 20ns approx.
- SS: no idea, did not check.
 
IBM said it had 'improved' its CMOS processors since then, but I do not
know whether this includes 'improved' RR times.
 
As regards loops, try to ensure that they fit entirely within the
instruction register (was 128 bytes) to avoid instruction cache faults. 
 
E.g. try something like the following (adjust as required) to see what
happens with instruction cache faults:
WHATEVER CSECT OUR ENTRY POINT
 USING WHATEVER,15 USE R15 AS OUR BASE REGISTER
INIT STM   14,12,12(13)    STORE CALLER'S REGISTERS
         ST    13,SAVEAREA+4   OUR BACKWARD POINTER
 LR    4,13    USE R4 AS TEMP CALLER'S R13
 LA    13,SAVEAREA USE R13 FOR OUR SAVEAREA
         ST    13,8(4)             CALLER'S FORWARD POINTER
 LHI   4,4096*512  USE R4 AS OUTER LOOP COUNTER
*
OUTLOOP  CNOP  0,4 OUTER LOOP START
 LHI   5,4096*1024     USE R5 AS INNER LOOP COUNTER
*
INLOOP   CNOP  0,4                 INNER LOOP START
B    CONTINUE  BRANCH PAST INSTRUCTION CACHE STORAGE
IN   DS    F   STORAGE INSIDE INSTRUCTION CACHE
CONTINUE DS    0F  NOW CARRY ON
 ST    5,OUT   STORE R5 OUTSIDE THE INSTRUCTION
CACHE  <--
*    ST    5,IN    STORE R5 INSIDE  THE INSTRUCTION
CACHE  <--
 BCT   5,INLOOP    DECREMENT AND BACK TO INNER LOOP
 BCT   4,OUTLOOP   DECREMENT AND BACK TO OUTER LOOP
FILL     DS    XL(132+WHATEVER-*)  FILL UP THE INSTRUCTION CACHE
OUT  DS    F   STORAGE OUTSIDE INSTRUCTION CACHE
SAVEAREA DS    18F OUR REGISTER SAVE AREA
*
EXIT L 13,4(13)    RESTORE CALLER'S REGISTERS
 LM    14,12,12(13)
 BR    14  BACK TO CALLER
 END   WHATEVER    START AT WHATEVER'S EP

An above "ST   5,IN" causes an instruction cache fault at every INLOOP
iteration, which results in approx 20 times more CPU than the "ST   5,OUT".
 
When possible use registers instead of L2 cache for temporary storage,
because registers (RR) are much faster than storage to storage
operations (SS).
 
Avoid MVCL: use MVC iteratively in a loop.
 
HTH. 
 
Cheers, Chris Poncelet (retired sysprog)

 
 
 


On 13/08/2019 16:39, Steve Smith wrote:
> Write good code and forget about instruction timings.  With any luck your
> code will have to perform on several generations of architecture and
> machines.
>
> There's a big difference between B- (base-index-displacement) branches and
> J- (or BR-) (relative address) instructions.  Surely by now, this should go
> without saying.  Regardless of whether they're "faster" or not, they are
> much better, and as that is well-documented, I won't belabor it.
>
> sas
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>


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

Re: Instruction speeds

[CM Poncelet]

BTW Change "LHI   4,4096*512" and "LHI   5,4096*1024" to something like
"LHI   4,4096*16-1"etc. or it will not fit in a halfword - just wrote it
"off the top of my head" without checking. :-(
 

On 14/08/2019 03:24, CM Poncelet wrote:
> FWIW
>  
> On the Hitachi Skyline bipolar mainframe (from 1995), the instruction
> processor speeds were:
> - RR: 3ns.
> - SS: 6-10ns if L2 cached, else 60-80ns if data-fetched from central
> storage.
>  
> On IBM's CMOS G4 mainframes:
> - RR: 20ns approx.
> - SS: no idea, did not check.
>  
> IBM said it had 'improved' its CMOS processors since then, but I do not
> know whether this includes 'improved' RR times.
>  
> As regards loops, try to ensure that they fit entirely within the
> instruction register (was 128 bytes) to avoid instruction cache faults. 
>  
> E.g. try something like the following (adjust as required) to see what
> happens with instruction cache faults:
> WHATEVER CSECT OUR ENTRY POINT
>  USING WHATEVER,15 USE R15 AS OUR BASE REGISTER
> INIT STM   14,12,12(13)    STORE CALLER'S REGISTERS
>          ST    13,SAVEAREA+4   OUR BACKWARD POINTER
>  LR    4,13    USE R4 AS TEMP CALLER'S R13
>  LA    13,SAVEAREA USE R13 FOR OUR SAVEAREA
>          ST    13,8(4)             CALLER'S FORWARD POINTER
>  LHI   4,4096*512  USE R4 AS OUTER LOOP COUNTER
> *
> OUTLOOP  CNOP  0,4 OUTER LOOP START
>  LHI   5,4096*1024     USE R5 AS INNER LOOP COUNTER
> *
> INLOOP   CNOP  0,4                 INNER LOOP START
> B    CONTINUE  BRANCH PAST INSTRUCTION CACHE STORAGE
> IN   DS    F   STORAGE INSIDE INSTRUCTION CACHE
> CONTINUE DS    0F  NOW CARRY ON
>  ST    5,OUT   STORE R5 OUTSIDE THE INSTRUCTION
> CACHE  <--
> *    ST    5,IN    STORE R5 INSIDE  THE INSTRUCTION
> CACHE  <--
>  BCT   5,INLOOP    DECREMENT AND BACK TO INNER LOOP
>  BCT   4,OUTLOOP   DECREMENT AND BACK TO OUTER LOOP
> FILL     DS    XL(132+WHATEVER-*)  FILL UP THE INSTRUCTION CACHE
> OUT  DS    F   STORAGE OUTSIDE INSTRUCTION CACHE
> SAVEAREA DS    18F OUR REGISTER SAVE AREA
> *
> EXIT L 13,4(13)    RESTORE CALLER'S REGISTERS
>  LM    14,12,12(13)
>  BR    14  BACK TO CALLER
>  END   WHATEVER    START AT WHATEVER'S EP
>
> An above "ST   5,IN" causes an instruction cache fault at every INLOOP
> iteration, which results in approx 20 times more CPU than the "ST   5,OUT".
>  
> When possible use registers instead of L2 cache for temporary storage,
> because registers (RR) are much faster than storage to storage
> operations (SS).
>  
> Avoid MVCL: use MVC iteratively in a loop.
>  
> HTH. 
>  
> Cheers, Chris Poncelet (retired sysprog)
>
>  
>  
>  
>
>
> On 13/08/2019 16:39, Steve Smith wrote:
>> Write good code and forget about instruction timings.  With any luck your
>> code will have to perform on several generations of architecture and
>> machines.
>>
>> There's a big difference between B- (base-index-displacement) branches and
>> J- (or BR-) (relative address) instructions.  Surely by now, this should go
>> without saying.  Regardless of whether they're "faster" or not, they are
>> much better, and as that is well-documented, I won't belabor it.
>>
>> sas
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> .
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

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

Re: Instruction speeds

[Jim Mulder]

  This link has been posted here before, but in case anyone missed it,


https://www.ibm.com/developerworks/community/files/form/anonymous/api/library/ff4563be-756e-49bf-9de9-6a04a08026f1/document/07c69512-ac74-4394-87b9-a61ea201347e/media/IBMzSystemsProcessorOptimizationPrimerv2.pdf


Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY



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

Re: Mainframes testing

[zMan]

ITYM "surfeit" -- too MANY commenting without knowledge! But we knew what
you meant.

On Tue, Aug 13, 2019 at 8:54 AM Aled Hughes <
0050619ca8df-dmarc-requ...@listserv.ua.edu> wrote:

>  You and me both Lennie
>
> "Abby is a seasoned marketing and public relations professional."
> Reminds me that a journalist called Ruth Sunderland was on the radio the
> other day stating that the airline British Airways (after a failure) "is
> riddled with old systems that have been in place for many years and have
> become creaky and inefficient. Replacing them without major disruptions is
> a Herculean job." She even stated that 'mainframes' were to blame for the
> 2018 TSB fiasco.
>
> As someone recently said, "We have a dearth of experts commenting on the
> mainframe world, without knowing anything about mainframes."
> ALH
>
>
>
>
>
>
>
>
> -Original Message-
> From: Lennie Dymoke-Bradshaw 
> To: IBM-MAIN 
> Sent: Tue, 13 Aug 2019 10:29
> Subject: Re: Mainframes testing
>
> Filip,
>
> The IBM paper reads as if it has been written by someone with relatively
> little System z knowledge.
>
> " There can also be security flaws created during the
> set-up of permissions for libraries. Libraries are modules for
> coding. They call into the code and should only be accessed
> by people who have the highest level of permission."
>
> I am not even sure what the above means.
>
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:  www.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Filip Palian
> Sent: 13 August 2019 02:17
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [IBM-MAIN] Mainframes testing
>
> Hey List,
>
> This can be of interest to some:
>
> -
> https://securityintelligence.com/posts/top-five-security-focus-areas-for-mainframes/
> - https://www.ibm.com/downloads/cas/A9NKZ8WE
>
> Any thoughts/comments?
>
>
> Thanks,
> Filip
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: Mainframes testing

[Jon Perryman]

 Is IBM trying to get out of z/OS? Abby Ross states "passwords and confidential 
information should not be on the mainframe because they are exposed to any type 
of user". This article is about selling IBM services and moving to Unix. So 
called experts yet she and her team obviously don't understand z/OS security. 
She gives a list of Unix security exposures. I'll go thru them shortly.
It's sad that these so called IBM security experts give out such bad advice to 
their customers. The actual solution is to treat z/OS Unix security exactly the 
same as any other Unix system. Unix programmers get the flexibility to do 
everything but with that comes the responsibility to learn corporate Unix 
security standards. z/OS Unix must comply with both corporate standards (Unix 
and z/OS).
Item 1 - password policies: In what world is an 8 character passwords easily 
guessed in 10 attempts? She even thinks hackers will have a whole day to crack 
it. Even worse she sites a colleagues example of Windows active directory 
services breach exposing a z/OS user's password. Is she saying that Unix 
doesn't have this exposure with Windows Active Directory Services? If not, then 
what corporate standard is z/OS Unix missing?

Item 2 - data left behind: When was MVS ever a setup and forget system? Planned 
properly then much of the security will occur naturally (e.g. naming 
conventions). Fewer people are needed to maintain z/OS corporate standards 
because they are very easy to follow.
"Certain data should be secured". Obviously but people must follow corporate 
standards (e.g. naming conventions or the equivalent Unix standard).
"Sensitive data should be deleted". In Unix, why bother with deletion when you 
can't delete from the backups. The only solution for any Unix system is to 
properly protect the data. Deleting datasets from z/OS and HSM is trivial but 
why bother when it's properly secured in the first place.

"passwords and confidential information should not be on the mainframe because 
they are exposed to any type of user" totally boggles the mind. They think it's 
a great idea to move sensitive data to systems that are getting hacked all the 
time (do a web search for the last year to see the reported cases).
"They had a hacker who found privileged data". People make fewer (and far less 
impact) security mistakes on z/OS than Unix. Think back to that web search.  
Item 3: over-privileged users. Most people forget 90% of the z/OS users are 
either CICS and IMS who don't have direct access to any datasets and often 
restricted to specific transactions. How many of the remaining 10% are 
considered over-privileged by their companies policies? Is that mostly z/OS 
Unix where they aren't following corporate Unix standards?
Item 4: unencrypted protocols. Specifically she sites "TN3270 defaults to 
unencrypted for webservers". z/OS TN3270 easily supports SSL encryption. 
Doesn't the blame belong to the a web server not using the SSL port? This is a 
usage issue instead of a technical issue. Set a corporate standard and everyone 
must follow.
Item 5: insecure applications. Security in CICS, IMS, TSO and batch are hidden 
with very few exceptions (e.g. TCP sockets). There are only 3 commonly used 
security products (RACF, ACF2 and Top-Secret) and they are so heavily used that 
testing is considered far superior to Unix equivalents.
Unix gives programmers the flexibility to implement anything they want. Because 
this flexibility includes security, they have the responsibility to test what 
ever security they implement. Who takes responsibility for all the freeware in 
use by those applications (huge list)? How about frameworks (software bundles)? 
How about each programmer's set of utilities and tools? Do you really think 
most Unix systems are being properly validated?  
The biggest factor in security is human. z/OS has greatly reduced that 
exposure. Unix needs to grow up and take responsibility for it's failures. Or 
maybe we just need another 100 API's, frameworks and utilities.
Jon.
On Tuesday, August 13, 2019, 06:57:59 AM PDT, Charles Mills 
 wrote:  
 
 I disagree somewhat with the other two commenters.

The papers are NOT an advanced how-to for RACF administrators! (For that, see 
the DISA STIGs!) But they are a decent intro for a manager who is ignorant of 
-- and frankly, need not be concerned with -- configuration details. They 
weren't written for readers of this list -- but think about your manager or his 
boss ...

The first paper is pretty good IMHO. Would anyone disagree that the five 
vulnerabilities listed are at least among the top ten or so vulnerabilities?

The second paper is certainly airline magazine level. Yeah, the quote cited by 
Lennie makes absolutely no sense. But there are some good points in there. 
Would anyone disagree with the following? Would anyone say it would NOT be good 
if every CIO at a mainframe organization read the following?

The mainframe
was and is critical to commercial d

Integrated 3270 Console in HMC 2.12 in web browser

[Christian Svensson]

Hi,

Is it possible to launch Integrated 3270 Console in HMC 2.12 when accessing
the HMC using a web browser?

When I click on the LPAR and choose Integrated 3270 Console nothing happens
when using a remote web browser. It works locally on the HMC. The Chrome
network request is:

Request URL: https:///hmc/ui/dnd2/launch
Request Method: POST
Status Code: 204 No Content
Remote Address: 10.114.2.10:443
Referrer Policy: no-referrer-when-downgrade
Date: Wed, 14 Aug 2019 06:00:22 GMT
Server: zSeries management console embedded web server / 2.0

Nothing more. Am I missing something? Some other actions at least say "this
task cannot be used remotely" which makes me wonder if I'm doing something
wrong.

Bonus question: Can I connect to the LPAR 3270 console remotely in some
other fashion?

Thanks,

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

Re: Instruction speeds

[David Crayford]

Some interesting information on branch prediction in that paper.

If you've got a z/OS C++ compiler try this snippet out, it's fascinating:

https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array

On 2019-08-13 11:47 PM, Charles Mills wrote:

A GREAT introduction to this topic, by someone who unlike me actually knows 
what he is talking about:

https://linuxmain.blogspot.com/2017/02/zoptimizationprimer.html

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Chapman
Sent: Monday, August 12, 2019 5:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Instruction speeds

Hi everyone,

I did some searching, but I didn't find anything that really discussed this
on the topic that I'm interested. Is there anything published that compares
the cycle times of the most used instructions?

For example; moving an address between areas of storage. I would assume
that executing a LOAD and STORE would be much quicker than executing a MVC.

Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
WORD.

Or does this really matter as much as ordering the instructions so they are
optimized for the pipeline?

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

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


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

Re: Instruction speeds

[Vernooij, Kees (ITOP NM) - KLM]

And: don't write unnecessary code. 
A nice example is how to determine leap years: from as long as I program the 
flow is:
- dividable by 4?
- dividable by 100?
- dividable by 400?

The last 2 are completely unnecessary until the year 2100. 
How many useless instructions will have been executed for this reason in the 
150 years until 2100?
How much of our assembler code will live until 2100? Lots were not even 
prepared for 2000.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Seymour J Metz
> Sent: 13 August, 2019 19:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
> 
> Avoid processor-specific optimizations; what is millicode on one box may
> not be on another. Worry first about getting your code correct and
> maintainable.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List  on behalf
> of Christopher Y. Blaicher 
> Sent: Monday, August 12, 2019 9:32 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
> 
> There is no instruction cycle time table.  There are some general
> guidelines you can follow.
> 
> Don't overload cache.  Locality of reference for instructions and data is
> important.
> 
> The machine will do out-of-order instruction processing, but there are
> limits.  If you load a register don't use it as a base register in the
> next instruction, if you can help it.
> 
> MVC is a lot faster than MVCL.  A series of MVC's will beat a MVCL up to
> about 32K.
> 
> JUMPs are faster than BRANCHes.
> 
> Don't use instructions that set the condition code, unless you need it.
> 
> Millicode instructions have startup and shutdown overheads.  Many times
> you can go faster using open code to do what a millicode instruction does.
> 
> Here is one that has nothing to do with an instruction - Don't assign CPs
> from different drawers to an LPAR, that includes ZIIPs.  Task switching
> across drawers kills cache and kills performance.  You will lose hundreds,
> if not thousands, of cycles.
> 
> There are some articles on the net that go over processor design and cache
> design.  The processor designs will give you a hint to the number of
> stages an instruction goes through.  Pipeline delays are what you try to
> avoid.
> 
> Chris Blaicher
> Technical Architect
> Syncsort, Inc.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Chapman
> Sent: Monday, August 12, 2019 8:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Instruction speeds
> 
> Hi everyone,
> 
> I did some searching, but I didn't find anything that really discussed
> this on the topic that I'm interested. Is there anything published that
> compares the cycle times of the most used instructions?
> 
> For example; moving an address between areas of storage. I would assume
> that executing a LOAD and STORE would be much quicker than executing a
> MVC.
> 
> Or executing a LOAD ADDRESS to increment a register instead of ADD HALF
> WORD.
> 
> Or does this really matter as much as ordering the instructions so they
> are optimized for the pipeline?
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--

Re: Instruction speeds

[Vernooij, Kees (ITOP NM) - KLM]

It may be fast, but it runs a long time. Talking about 'speed'!

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rick J. Valles
> Sent: 13 August, 2019 18:13
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Instruction speeds
> 
> Here’s my IEFBR15 “Utility” - it’s pretty fast:
> 
>   Active Usings: None
>   Loc  Object CodeAddr1 Addr2  Stmt   Source Statement
> 000 2 1 IEFBR15  CSECT
> 00 07FF   2  BR15
>   3  END
> 
> :)
> 
> 
> r
> 
> > On Aug 13, 2019, at 10:09 AM, Brian Chapman 
> wrote:
> >
> > Thanks Charles and Steve.
> >
> > Now that I am becoming a more experience assembler programmer, I have
> > wondered if I should be greatly concerned about instruction timings or
> > pipeline order, or just simply focus on readability and maintenance.
> > Especially since assembler programming is becoming a dying art. I think
> I
> > am only 1 of a handful of assembler programmers at my shop with hundreds
> of
> > mainframe programmers! I think you both answered my question. Thanks!
> >
> >
> >
> > Thank you,
> >
> > Brian Chapman
> >
> >
> > On Tue, Aug 13, 2019 at 11:39 AM Steve Smith  wrote:
> >
> >> Write good code and forget about instruction timings.  With any luck
> your
> >> code will have to perform on several generations of architecture and
> >> machines.
> >>
> >> There's a big difference between B- (base-index-displacement) branches
> and
> >> J- (or BR-) (relative address) instructions.  Surely by now, this
> should go
> >> without saying.  Regardless of whether they're "faster" or not, they
> are
> >> much better, and as that is well-documented, I won't belabor it.
> >>
> >> sas
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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