Re: Constant Identifiers

[Paul Gilmartin]

On Sat, 5 Sep 2020 08:13:42 +1000, Robin Vowels wrote:
>
>As for writing formulas, I prefer to follow a well-known formula, thus:
>
>volume = 4/3 * 3.14159 * radius**3
> 
Beware!  Than might left-associate as:
volume = ( 4/3 ) * 3.14159 * radius**3
... and the quotient of integers, 4/3, is 1.

>However, if I'm interested in efficiency, I'd prefer
>
>volume = 4 * 3.14159E0 / 3 * radius**3
> 
... (and correct.)

-- gil

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

Re: Constant Identifiers

[Robin Vowels]

That's obfuscation.
If it's in a loop,  I'd expect the compiler to move the constant part outside 
of the loop,
or to evaluate the constant part at compilation time.

In any case, the more efficient form eliminates the division 4/3,
avoiding the avaluation in fixed-point form (and the conversion
to floating-point).

- Original Message - 
From: "Bob Bridges" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Sunday, September 06, 2020 6:18 AM
Subject: Re: Constant Identifiers



When you care about efficiency, I'd think this would be better:

 const=4/3*3.14159E0 /* in the initialization */
 volume=const*radius**3 /* inside the loop */

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Things may come to those who wait, but only those things left behind by
those who hustle.  -attributed (probably falsely) to Abraham Lincoln, lawyer
*/

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Robin Vowels
Sent: Friday, September 4, 2020 18:14

As for writing formulas, I prefer to follow a well-known formula, thus:

  volume = 4/3 * 3.14159 * radius**3

However, if I'm interested in efficiency, I'd prefer

  volume = 4 * 3.14159E0 / 3 * radius**3


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: REXX true/false (was Constant Identifiers)

[Robin Vowels]

On 2020-09-06 11:50, Seymour J Metz wrote:

Eschew obfuscation. Either just use 0 and one, or write
false=0;true=1. Similarly, for PL/I either just use '0'b and '1'b or
write false='0'b;true='1'b;.


VALUE is a good alternative also.

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

Re: Constant Identifiers

[Seymour J Metz]

The issue in contention is the wording of the text, not its location. I never 
claimed that it was in the right manual.


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



From: IBM Mainframe Discussion List  on behalf of 
Robin Vowels 
Sent: Friday, September 4, 2020 9:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Constant Identifiers

"Seymour J Metz"  wrote in message
news:bl0pr05mb5156e311e88735a8afbef5ca99...@bl0pr05mb5156.namprd05.prod.outlook.com...

> If you don't care about maintainable code than should is to strong.
> If you care about maintainable code then should is too weak.


The purpose of a LRM is to tell you what facilities are available.

Not to impose programming conventions or rules -- that's the
prerogative of the installation.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
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: REXX true/false (was Constant Identifiers)

[Seymour J Metz]

Eschew obfuscation. Either just use 0 and one, or write false=0;true=1. 
Similarly, for PL/I either just use '0'b and '1'b or write 
false='0'b;true='1'b;.


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



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Saturday, September 5, 2020 4:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: REXX true/false (was Constant Identifiers)

 I've never done that, but I have done something like it:

  str=word('true false',(0-fx)+2)

...where fx is Boolean.  I hope I've done it only in programs I wrote for my 
own use.  But I sometimes write a tool for myself, then move it to a public 
library on request, so that monster may be out there somewhere.

(If I have to explain it, it just proves I should never write it that way in 
the first place.  This is better:

  if fx then str='true'; else str=true

But it sometimes pleases me to be too clever for my own good.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* In its state of nature [a dog] has a smell, and habits, which frustrate 
man's love; he washes it, house-trains it, teaches it not to steal, and is so 
enabled to love it completely.  To the puppy, the whole proceeding would seem, 
if it were a theologian, to cast grave doubts on the "goodness" of man; but the 
full-grown and full-trained dog, larger, healthier and longer-lived than the 
wild dog, and admitted, as it were by Grace, to a whole world of affections, 
loyalties, interests and comforts entirely beyond its animal destiny, would 
have no such doubt.  -C S Lewis, _The Problem of Pain_ */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, September 4, 2020 13:01

In Rexx I have sometimes, perhaps mischievously, replaced:
IF (var_a = var_b) THEN
THEN temp_var = some_string
ELSE tenp_var = ''
say string_a || temp_var || string_b

with:
say string_a || copies( some_string, (var_a = var_b) )string_b

to save a few lines of code.

--
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: Constant Identifiers

[Seymour J Metz]

Don't most compilers these days do constant folding?


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



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Saturday, September 5, 2020 4:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Constant Identifiers

When you care about efficiency, I'd think this would be better:

  const=4/3*3.14159E0 /* in the initialization */
  volume=const*radius**3 /* inside the loop */

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Things may come to those who wait, but only those things left behind by
those who hustle.  -attributed (probably falsely) to Abraham Lincoln, lawyer
*/

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Robin Vowels
Sent: Friday, September 4, 2020 18:14

As for writing formulas, I prefer to follow a well-known formula, thus:

   volume = 4/3 * 3.14159 * radius**3

However, if I'm interested in efficiency, I'd prefer

   volume = 4 * 3.14159E0 / 3 * radius**3

--
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: Constant Identifiers

[Seymour J Metz]

When you're dealing with small integers that stand for themselves, theres 
neither benfit nor harm for making them named constants. It's "magic numbers" 
that you need to avoid, e.g., approximations, exchange rates.


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



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Saturday, September 5, 2020 4:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Constant Identifiers

Going back to the beginning, Gil:  SQRT(X**TWO+Y**TWO) looks like ~exactly~ the 
sort of thing that oughta be made a constant rather than being coded more than 
once.  That is, if X, Y and TWO all constants themselves; and if they are not 
then this isn't an example of what you're talking about.  Did you accidentally 
reverse your meaning?  Or what am I missing?

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Anarchy might be great, if only it could be enforced.  -Joseph Sobran, 
2001-03-27 */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, September 4, 2020 11:44

I'm a PL/I novice, or less.  A recent thread here moved me
to browse the Ref., where I read that any constant used more
than once must be declared and the identifier used instead.
Sorta tyrannical enforcement of coding conventions.  OK.
I agree that 6.62607015e−34 shouldn't be hard-coded more
than once.  But SQRT( X**TWO + Y**TWO )?  Ugh!

--
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: REXX true/false (was Constant Identifiers)

[Paul Gilmartin]

On Sat, 5 Sep 2020 23:36:37 +0100, Rupert Reynolds wrote:

>Writing Rexx for myself (therefore no local standards to follow) I had to
>set an internal boolean in a few places.
>So I started it with
>TRUE = (1=1)
>FALSE = \TRUE
>
Now you have them; how are they useful?  (Examples?)

>That's partly because I couldn't find doc on Rexx standards (no WWW yet)
>and I didn't like to assume that 1 and 0 were always valid :-)
>
https://webstore.ansi.org/standards/incits/ansiincits2741996r2007
$60.00

-- gil

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

Re: REXX true/false (was Constant Identifiers)

[Rupert Reynolds]

Writing Rexx for myself (therefore no local standards to follow) I had to
set an internal boolean in a few places.
So I started it with
TRUE = (1=1)
FALSE = \TRUE

That's partly because I couldn't find doc on Rexx standards (no WWW yet)
and I didn't like to assume that 1 and 0 were always valid :-)

Roo

On Sat., Sep. 5, 2020, 22:48 Paul Gilmartin, <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sat, 5 Sep 2020 16:09:32 -0400, Bob Bridges wrote:
> >
> >  str=word('true false',(0-fx)+2)
> >
> >...where fx is Boolean.
> >
> My use of COPIES() was to save 2 lines of code while knowing that
> the function call/return overhead is large and IF would perform better.
>
> >  if fx then str='true'; else str=true
> >
> ???  So if fx is 1 this sets str to "true"; if fx is 0 this sets str to
> "TRUE"?
>
> But I'd rather do:
> parse value 0 1 with false true.
> Or perhaps mischievously:
> parse value (2+2=5) (2+2=4) with false true .
>
> ... and have useful(?) constant identifiers.  But I can think of
> few places other than function arguments where using Boolean
> constant identifiers improves either performance or legibility.
>
>
> On Sat, 5 Sep 2020 16:18:47 -0400, Bob Bridges wrote:
> >
> >When you care about efficiency, I'd think this would be better:
> >
> >  const=4/3*3.14159E0 /* in the initialization */
> >  volume=const*radius**3 /* inside the loop */
> >
> I leave it to the compiler to perform that sort of constant
> folding.  Most of them do.  Same for reordering operands.
> A programmer computing volumes in several places might
> declare a function (which the compiler should expand inline.)
>
>
> On Sat, 5 Sep 2020 16:21:51 -0400, Bob Bridges wrote:
> >
> >Going back to the beginning, Gil:  SQRT(X**TWO+Y**TWO) looks like
> ~exactly~ the sort of thing that oughta be made a constant rather than
> being coded more than once.  That is, if X, Y and TWO all constants
> themselves; and if they are not then this isn't an example of what you're
> talking about.  Did you accidentally reverse your meaning?  Or what am I
> missing?
> >
> No.  I was assuming that X and Y are variables, perhaps function
> arguments and playing off the Lang. Ref's assertion (almost surely
> wrong, but I can't test it) that any constant (such as 2) occurring
> more than once *must* be declared and referenced as an identifier.
>
> >---
> >/* Anarchy might be great, if only it could be enforced.  -Joseph Sobran,
> 2001-03-27 */
> >
> A couple decades ago I saw signs spray-painted on pavements and
> walls touting the Boulder Anarchist Party.  I thought that Anarchists
> shouldn't have political parties.  But how could that be enforced?
>
> -- 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: REXX true/false (was Constant Identifiers)

[Paul Gilmartin]

On Sat, 5 Sep 2020 16:09:32 -0400, Bob Bridges wrote:
>
>  str=word('true false',(0-fx)+2)
>
>...where fx is Boolean.  
> 
My use of COPIES() was to save 2 lines of code while knowing that
the function call/return overhead is large and IF would perform better.

>  if fx then str='true'; else str=true
>
???  So if fx is 1 this sets str to "true"; if fx is 0 this sets str to "TRUE"?

But I'd rather do:
parse value 0 1 with false true.
Or perhaps mischievously:
parse value (2+2=5) (2+2=4) with false true .

... and have useful(?) constant identifiers.  But I can think of
few places other than function arguments where using Boolean
constant identifiers improves either performance or legibility.


On Sat, 5 Sep 2020 16:18:47 -0400, Bob Bridges wrote:
>
>When you care about efficiency, I'd think this would be better:
>
>  const=4/3*3.14159E0 /* in the initialization */
>  volume=const*radius**3 /* inside the loop */
>
I leave it to the compiler to perform that sort of constant
folding.  Most of them do.  Same for reordering operands.
A programmer computing volumes in several places might
declare a function (which the compiler should expand inline.)


On Sat, 5 Sep 2020 16:21:51 -0400, Bob Bridges wrote:
>
>Going back to the beginning, Gil:  SQRT(X**TWO+Y**TWO) looks like ~exactly~ 
>the sort of thing that oughta be made a constant rather than being coded more 
>than once.  That is, if X, Y and TWO all constants themselves; and if they are 
>not then this isn't an example of what you're talking about.  Did you 
>accidentally reverse your meaning?  Or what am I missing?
> 
No.  I was assuming that X and Y are variables, perhaps function
arguments and playing off the Lang. Ref's assertion (almost surely
wrong, but I can't test it) that any constant (such as 2) occurring
more than once *must* be declared and referenced as an identifier.

>---
>/* Anarchy might be great, if only it could be enforced.  -Joseph Sobran, 
>2001-03-27 */
>
A couple decades ago I saw signs spray-painted on pavements and
walls touting the Boulder Anarchist Party.  I thought that Anarchists
shouldn't have political parties.  But how could that be enforced?

-- gil

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

Re: Constant Identifiers

[Jeremy Nicoll]

On Sat, 5 Sep 2020, at 21:21, Bob Bridges wrote:
> Going back to the beginning, Gil:  SQRT(X**TWO+Y**TWO) looks like 
> ~exactly~ the sort of thing that oughta be made a constant rather than 
> being coded more than once.  That is, if X, Y and TWO all constants 
> themselves; and if they are not then this isn't an example of what 
> you're talking about.  Did you accidentally reverse your meaning?  Or 
> what am I missing?

He meant defining  TWO = 2   earlier.

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: REXX true/false (was Constant Identifiers)

[Jeremy Nicoll]

On Sat, 5 Sep 2020, at 21:09, Bob Bridges wrote:
>  I've never done that, but I have done something like it:
> 
>   str=word('true false',(0-fx)+2)

Why   (0-fx)+2when  2-fxis simpler?

 
> (If I have to explain it, it just proves I should never write it that 
> way in the first place.  This is better:
> 
>   if fx then str='true'; else str=true

Not really.  That might as well have been

   str =  "true"

but somewhat pointless.  (Sorry.)

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: Constant Identifiers

[Bob Bridges]

Going back to the beginning, Gil:  SQRT(X**TWO+Y**TWO) looks like ~exactly~ the 
sort of thing that oughta be made a constant rather than being coded more than 
once.  That is, if X, Y and TWO all constants themselves; and if they are not 
then this isn't an example of what you're talking about.  Did you accidentally 
reverse your meaning?  Or what am I missing?

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Anarchy might be great, if only it could be enforced.  -Joseph Sobran, 
2001-03-27 */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, September 4, 2020 11:44

I'm a PL/I novice, or less.  A recent thread here moved me
to browse the Ref., where I read that any constant used more
than once must be declared and the identifier used instead.
Sorta tyrannical enforcement of coding conventions.  OK.
I agree that 6.62607015e−34 shouldn't be hard-coded more
than once.  But SQRT( X**TWO + Y**TWO )?  Ugh!

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

Re: Constant Identifiers

[Bob Bridges]

When you care about efficiency, I'd think this would be better:

  const=4/3*3.14159E0 /* in the initialization */
  volume=const*radius**3 /* inside the loop */

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Things may come to those who wait, but only those things left behind by
those who hustle.  -attributed (probably falsely) to Abraham Lincoln, lawyer
*/

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Robin Vowels
Sent: Friday, September 4, 2020 18:14

As for writing formulas, I prefer to follow a well-known formula, thus:

   volume = 4/3 * 3.14159 * radius**3

However, if I'm interested in efficiency, I'd prefer

   volume = 4 * 3.14159E0 / 3 * radius**3

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

Re: Constant Identifiers

[Bob Bridges]

Gotta side with Robin on that one.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Law #37 of combat operations:  Anything you do can get you killed, including 
nothing. */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robin Vowels
Sent: Friday, September 4, 2020 21:04

The purpose of a LRM is to tell you what facilities are available.

Not to impose programming conventions or rules -- that's the
prerogative of the installation. 

--- "Seymour J Metz"  wrote...
> If you don't care about maintainable code than should is to strong.
> If you care about maintainable code then should is too weak.

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

REXX true/false (was Constant Identifiers)

[Bob Bridges]

 I've never done that, but I have done something like it:

  str=word('true false',(0-fx)+2)

...where fx is Boolean.  I hope I've done it only in programs I wrote for my 
own use.  But I sometimes write a tool for myself, then move it to a public 
library on request, so that monster may be out there somewhere.

(If I have to explain it, it just proves I should never write it that way in 
the first place.  This is better:

  if fx then str='true'; else str=true

But it sometimes pleases me to be too clever for my own good.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* In its state of nature [a dog] has a smell, and habits, which frustrate 
man's love; he washes it, house-trains it, teaches it not to steal, and is so 
enabled to love it completely.  To the puppy, the whole proceeding would seem, 
if it were a theologian, to cast grave doubts on the "goodness" of man; but the 
full-grown and full-trained dog, larger, healthier and longer-lived than the 
wild dog, and admitted, as it were by Grace, to a whole world of affections, 
loyalties, interests and comforts entirely beyond its animal destiny, would 
have no such doubt.  -C S Lewis, _The Problem of Pain_ */

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, September 4, 2020 13:01

In Rexx I have sometimes, perhaps mischievously, replaced:
IF (var_a = var_b) THEN
THEN temp_var = some_string
ELSE tenp_var = ''
say string_a || temp_var || string_b

with:
say string_a || copies( some_string, (var_a = var_b) )string_b

to save a few lines of code.

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

Re: Ransoming a mainframe disk farm

[Tom Brennan]

And to take this one step further (really one step too far), IBM boxes 
(DS and TS) have a built-in function called Secure Data Overwrite, so 
that before an old, replaced box goes out the door, the user can get a 
certification that all their old data is truly overwritten with multiple 
passes.  Some customers require this even if the box going out is 
encrypted with an external key, just to be sure.  The certification 
report shows the overwrites are at the internal disk level (not the 
logical tape level) so that should include anything that was once a 
Virtual WORM volume, directories, etc.


On a TS box this process seems to take days, so IBM does it remotely. 
Now, it could be they even *initiate* the process remotely.  If so, that 
would mean there's a slight possibility that a hacker who gains access 
to the machine via the IBM path could overwrite every byte on a tape 
box, making the encrypted ransomware disks far more valuable.


Disclaimer:  This is the first I've heard of a Virtual WORM volume, and 
despite what I said above, that sounds like an excellent solution to the 
problem.


On 9/5/2020 8:38 AM, Russell Witt wrote:

John,
But what happens if the virtual tape environment itself was over-written? That is where 
the concept of "virtual WORM" devices can help. A virtual WORM volume cannot be 
over-written. And if your tape management system itself is protected, the tapes will not 
be scratched until they should be (cycle control or GDG limit or xxx days). While the 
concept of a virtual WORM seems bizarre (its virtual, not physical) - the ability to 
protect against over-writing is a huge safe-guard if you are seriously worried about some 
type of insider threat. After all, the first thing a good insider hack would target is 
the audit trail of their own activities and most commonly that audit trail will be backed 
up on tape.
Russell Wittopinions are all my own (and I have a lot of them)


-Original Message-
From: John McKown 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sat, Sep 5, 2020 6:47 am
Subject: Re: Ransoming a mainframe disk farm

If I were to consider this (which I don't because my shop _is_ going away
1Q2021), what I would do is have a "golden image" (aka sysprog sandbox or
the GI) in a different LPAR. This image would have access to all attached
devices, including sharing a virtual tape environment. But the "core"
volumes would be _isolated_ from all other LPARs via the IODF / HCD. This
would include the GI specific catalogs (at least the master) and RACF (or
TSS or ACF2) database. The GI would do at least weekly backups of all the
volumes to the virtual tape. So the GI could be used to recover the other
systems' volumes.

If there is no virtual tape environment, then there needs to be a separate,
GI only, set of DASD which would be used for the backups of the real
volumes. Of course, this doubles the size of your DASD farm. For the truly
paranoid, and rich, this DASD would be on an entirely separate array which
is not accessible from any LPAR other than the GI LPAR.

Or, as I have actually done, use DFDSS (or FDR or ???) to make volume level
backups & download them to a USB drive. USB drives can be mind boggling
huge today. I saw a flash drive with 1TiB. But an USB attached SSD can be
even bigger. LIke this 16TiB USB 3.0 attached, encrypted, array: (there is
also a 30 TiB array -- of course you'll need a lot if you're talking about
a PetaByte environment).

https://smile.amazon.com/Buslink-CipherShield-CSE16TSSDB4SU3-Hardware-Encrypted/dp/B01JVVHYZM/ref=sr_1_2?dchild=1=usb+ssd_rd_r=5a1bbdc9-acaa-48d2-9518-4bcd087cd0d8_rd_w=OrRWX_rd_wg=6dxyr_rd_p=e47220c0-687b-448f-b180-4a20654b7464_rd_r=8BZ5ET5XHGMBMD3A23E7=1599306202=p_n_feature_three_browse-bin%3A6797522011=pc=1-2


On Fri, Sep 4, 2020 at 1:51 PM Jesse 1 Robinson 
wrote:


It’s Friday, so don’t rag on me for venturing into IT fiction. No one has
hit us with this challenge (yet), but it could happen.

Ransomware is much in the news these days. As unlikely as it might be,
some nefarious genius manages to lock you out of your entire disk farm and
demands rubies and bitcoin to remove the lock. Meanwhile your shop is out
of the water. You have everything meticulously mirrored to another site,
but as with any good mirror, the lock has been reflected in your recovery
site.

The classic mainframe response--short of forking over the ransom--would be
to IPL a standalone DSS restore tape, then locate and mount standard
offload backup tapes. Restore enough key volumes to IPL a minimal system,
then proceed to restore (all) other volumes. It will take a while, but it
will work. Eventually.

Now consider a smartly modern shop that has taken the advice of a
generation of hired gurus and eliminated 'real tape' altogether. No more
physical tapes. No more physical tape drives.

What would be your sage advice?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile

Re: Architectural Level Sets

[Dymoke-Bradshaw, Lennie]

I have a copy of the manual "Amdahl MVS/SP Assist Release 1.0 Software Logic 
Manual"  L1020.0-02A from October 1982. I recall we used this to run MVS/SP 1.3 
on old 370/158 machines. It would simulate the entire set of "new" cross-memory 
services instructions, such as MVCP, MVCS, PC, PT and so on.

Lennie Dymoke-Bradshaw
Consultant working on contract for BMC mainframe Services by RSM Partners
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: 03 September 2020 19:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Architectural Level Sets

It was probably some model of the 470V and MVS/SP 1.3.


--
Shmuel (Seymour J.) Metz
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3=DwIGaQ=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E=3UDd4E9ydP_Wheb7d5gow6pPKEFAD7WOFgBGu4v30s8=DwUZghnVEGFYge0Hwm727-6uVlyQZd1XOH27IzXGMOw=hj2QtB60QvQBtZlTl5N1yW2GEhq71FA9myBvSWmf4GA=
 



From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Thursday, September 3, 2020 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Architectural Level Sets

It's almost Friday. Back in the day when IBM had competitors in the hardware 
game, I worked at TRW Credit Data, ancestor of Experian. We had an Amdahl 
something-or-other. I was a baby sysprog at the time, so some details are 
fuzzy. A new iteration of MVS arrived that was designed *not* to run on an 
alien machine. (I believe it was MVS-SP1 circa 1980.) Trying to IPL it on 
Amdahl gear resulted in instant death because of new instructions.

So Amdahl to the rescue. They developed an ingenious usermod that replaced 
unexecutable instructions with either NOPs or invocations of Amdahl-supplied 
routines that simulated the function of the new instructions. These routines 
were initially invoked in response to 0C1 abends, but each offending 
instruction was then replaced in memory with a direct branch to the simulation 
routine. In effect as time wore on, the OS became more efficient.

I have no idea how IBM felt about this clever workaround, but it was certainly 
welcomed by Amdahl customers.

.
.
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 
Peter Relson
Sent: Thursday, September 3, 2020 9:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Architectural Level Sets

CAUTION EXTERNAL EMAIL


I was thinking more along the lines of things that prevented earlier operating 
systems from even IPLing on newer boxes. Such as z13 is the last processor to 
have ESA/390 mode  It depends how much earlier you are thinking of. A 
z/OS prior to OS/390
R10 would not work on a machine that is z/Arch-only.
A z/OS prior to z/OS 1.12 would not work on a machine that begins the IPL in 
z/Arch mode.

I don't happen to know what about the z990 would have caused an earlier release 
of the OS not to work.

In almost all cases, an old enough OS (specifically, one for which toleration 
support for a new machine was not provided) will not work properly because 
there are machine-related definitions that need to be accommodated  and those 
would not have been provided. But it might well IPL.

Peter Relson
z/OS Core Technology Design



--
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: Ransoming a mainframe disk farm

[Russell Witt]

John,
But what happens if the virtual tape environment itself was over-written? That 
is where the concept of "virtual WORM" devices can help. A virtual WORM volume 
cannot be over-written. And if your tape management system itself is protected, 
the tapes will not be scratched until they should be (cycle control or GDG 
limit or xxx days). While the concept of a virtual WORM seems bizarre (its 
virtual, not physical) - the ability to protect against over-writing is a huge 
safe-guard if you are seriously worried about some type of insider threat. 
After all, the first thing a good insider hack would target is the audit trail 
of their own activities and most commonly that audit trail will be backed up on 
tape. 
Russell Wittopinions are all my own (and I have a lot of them)


-Original Message-
From: John McKown 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Sat, Sep 5, 2020 6:47 am
Subject: Re: Ransoming a mainframe disk farm

If I were to consider this (which I don't because my shop _is_ going away
1Q2021), what I would do is have a "golden image" (aka sysprog sandbox or
the GI) in a different LPAR. This image would have access to all attached
devices, including sharing a virtual tape environment. But the "core"
volumes would be _isolated_ from all other LPARs via the IODF / HCD. This
would include the GI specific catalogs (at least the master) and RACF (or
TSS or ACF2) database. The GI would do at least weekly backups of all the
volumes to the virtual tape. So the GI could be used to recover the other
systems' volumes.

If there is no virtual tape environment, then there needs to be a separate,
GI only, set of DASD which would be used for the backups of the real
volumes. Of course, this doubles the size of your DASD farm. For the truly
paranoid, and rich, this DASD would be on an entirely separate array which
is not accessible from any LPAR other than the GI LPAR.

Or, as I have actually done, use DFDSS (or FDR or ???) to make volume level
backups & download them to a USB drive. USB drives can be mind boggling
huge today. I saw a flash drive with 1TiB. But an USB attached SSD can be
even bigger. LIke this 16TiB USB 3.0 attached, encrypted, array: (there is
also a 30 TiB array -- of course you'll need a lot if you're talking about
a PetaByte environment).

https://smile.amazon.com/Buslink-CipherShield-CSE16TSSDB4SU3-Hardware-Encrypted/dp/B01JVVHYZM/ref=sr_1_2?dchild=1=usb+ssd_rd_r=5a1bbdc9-acaa-48d2-9518-4bcd087cd0d8_rd_w=OrRWX_rd_wg=6dxyr_rd_p=e47220c0-687b-448f-b180-4a20654b7464_rd_r=8BZ5ET5XHGMBMD3A23E7=1599306202=p_n_feature_three_browse-bin%3A6797522011=pc=1-2


On Fri, Sep 4, 2020 at 1:51 PM Jesse 1 Robinson 
wrote:

> It’s Friday, so don’t rag on me for venturing into IT fiction. No one has
> hit us with this challenge (yet), but it could happen.
>
> Ransomware is much in the news these days. As unlikely as it might be,
> some nefarious genius manages to lock you out of your entire disk farm and
> demands rubies and bitcoin to remove the lock. Meanwhile your shop is out
> of the water. You have everything meticulously mirrored to another site,
> but as with any good mirror, the lock has been reflected in your recovery
> site.
>
> The classic mainframe response--short of forking over the ransom--would be
> to IPL a standalone DSS restore tape, then locate and mount standard
> offload backup tapes. Restore enough key volumes to IPL a minimal system,
> then proceed to restore (all) other volumes. It will take a while, but it
> will work. Eventually.
>
> Now consider a smartly modern shop that has taken the advice of a
> generation of hired gurus and eliminated 'real tape' altogether. No more
> physical tapes. No more physical tape drives.
>
> What would be your sage advice?
>
> .
> .
> 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
>
>
> --
> 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: Ransoming a mainframe disk farm

[Jonathan Quay]

We once had a database so valuable that it was mirrored to a remote site where 
8, 16, and 24 hour PIT copies of it were made.  We could do forward recovery 
from tape if needed.  This was more to protect against an application trashing 
the data than anything else.  It was hoped that data corruption would be 
noticed fairly quickly.

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

Re: zIIP MultiThreads

[Scott Chapman]

On Fri, 4 Sep 2020 09:22:09 -0700, Ed Jaffe  wrote:


>IMHO, if you need additional zIIP capacity for a production workload, it
>probably makes more sense to configure another zIIP core online than it
>does to enable MT=2.

Agreed. SMT is a good thing to keep in your pocket for the emergency of "we 
need a little more zIIP capacity, but we can't purchase another zIIP right 
now". Don't use it as a substitute for real zIIP capacity. If you need zIIP 
capacity buy more zIIP capacity. It's relatively inexpensive. 

1) The amount of extra throughput you'll get is variable depending on your 
workload mix. And the timing of the mix of workload. You can't use test to 
accurately predict production, you just have to try it. 

2) MT=2 is effectively more/slower engines vs. fewer/faster engines. This is a 
trade-off that's ok to good for most workloads, but is worth bearing in mind.

3) The measurements are complicated estimates based on instruction counts seen 
with 1 and 2 threads active that are not well documented. Most importantly, the 
reported zIIP time becomes MT1ET: the estimated time the work would have 
consumed on the zIIP had the zIIP been running in MT=1 instead of MT=2. But 
remember it's an estimate and based on numbers that change based on the 
instruction mix. Doing accurate capacity planning with estimates that vary this 
way is difficult. Which may not be a problem if your capacity planning for 
zIIPs is "when we start seeing cross-over to the GCPs we buy more zIIPs" (which 
is not necessarily a bad policy). 

SMT is a useful tool in certain situations, but IMHO, I wouldn't consider 
enabling MT=2 as the default. If you're having a problem that more zIIP 
capacity might help, then more real zIIP capacity is the best answer. In cases 
where that's impractical, MT=2 might be useful.

Scott Chapman

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

Re: Ransoming a mainframe disk farm

[John McKown]

If I were to consider this (which I don't because my shop _is_ going away
1Q2021), what I would do is have a "golden image" (aka sysprog sandbox or
the GI) in a different LPAR. This image would have access to all attached
devices, including sharing a virtual tape environment. But the "core"
volumes would be _isolated_ from all other LPARs via the IODF / HCD. This
would include the GI specific catalogs (at least the master) and RACF (or
TSS or ACF2) database. The GI would do at least weekly backups of all the
volumes to the virtual tape. So the GI could be used to recover the other
systems' volumes.

If there is no virtual tape environment, then there needs to be a separate,
GI only, set of DASD which would be used for the backups of the real
volumes. Of course, this doubles the size of your DASD farm. For the truly
paranoid, and rich, this DASD would be on an entirely separate array which
is not accessible from any LPAR other than the GI LPAR.

Or, as I have actually done, use DFDSS (or FDR or ???) to make volume level
backups & download them to a USB drive. USB drives can be mind boggling
huge today. I saw a flash drive with 1TiB. But an USB attached SSD can be
even bigger. LIke this 16TiB USB 3.0 attached, encrypted, array: (there is
also a 30 TiB array -- of course you'll need a lot if you're talking about
a PetaByte environment).

https://smile.amazon.com/Buslink-CipherShield-CSE16TSSDB4SU3-Hardware-Encrypted/dp/B01JVVHYZM/ref=sr_1_2?dchild=1=usb+ssd_rd_r=5a1bbdc9-acaa-48d2-9518-4bcd087cd0d8_rd_w=OrRWX_rd_wg=6dxyr_rd_p=e47220c0-687b-448f-b180-4a20654b7464_rd_r=8BZ5ET5XHGMBMD3A23E7=1599306202=p_n_feature_three_browse-bin%3A6797522011=pc=1-2


On Fri, Sep 4, 2020 at 1:51 PM Jesse 1 Robinson 
wrote:

> It’s Friday, so don’t rag on me for venturing into IT fiction. No one has
> hit us with this challenge (yet), but it could happen.
>
> Ransomware is much in the news these days. As unlikely as it might be,
> some nefarious genius manages to lock you out of your entire disk farm and
> demands rubies and bitcoin to remove the lock. Meanwhile your shop is out
> of the water. You have everything meticulously mirrored to another site,
> but as with any good mirror, the lock has been reflected in your recovery
> site.
>
> The classic mainframe response--short of forking over the ransom--would be
> to IPL a standalone DSS restore tape, then locate and mount standard
> offload backup tapes. Restore enough key volumes to IPL a minimal system,
> then proceed to restore (all) other volumes. It will take a while, but it
> will work. Eventually.
>
> Now consider a smartly modern shop that has taken the advice of a
> generation of hired gurus and eliminated 'real tape' altogether. No more
> physical tapes. No more physical tape drives.
>
> What would be your sage advice?
>
> .
> .
> 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
>
>
> --
> 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: Pascal(was: Constant Identifiers)

[Paul Gilmartin]

On Sat, 5 Sep 2020 12:06:49 +, Robert Prins wrote:
>
>... definitely not to keep myself in the picture.
>The simple fact is that I hate it that 'doze displays timestamps different in
>different time zones. So my TZ is UTC.
> 
The time is different in different timezones.  What do you expect?
You mean that when you travel westward you set your realtime
clock back and continue to call your timezone UTC?  (And Windows
lets you do that!?)  So files created at your destination might be
timestamped earlier than files created at your point of origin?
And you want that?

Reminiscent of the Bad Old Days when IBM advised customers to
shut down for an hour at the Fall Daylight Saving Time boundary.

>...
>An optimizing compiler, and none of the Pascal ones seem to fall into that
>category, should do this automagically.
>> 
Yes, but we were the compiler maintainers who had to code
that optimization.

>...
>You mean you used "get" and/or "put"? I've never ever used those, but Borland,
>Virtual and Free Pascal can ...
>
"We don't follow standards; what we do is better!"

My parser used "get" because it provided a one-character
lookahead, valuable for recognizing non-self-delimiting tokens.

Otherwise, "get" creates a PITA for terminal input:
https://en.wikipedia.org/wiki/Pascal_(programming_language)#File_type

-- gil

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

Re: zIIP MultiThreads

[Salva Carrasco]

We see 1.3 on  peak hours.

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

Re: Pascal(was: Constant Identifiers)

[Robert Prins]

On 2020-09-04 18:36, Paul Gilmartin wrote:

On Fri, 4 Sep 2020 20:38:29 +, Robert Prins wrote:


On 2020-09-04 17:01, Paul Gilmartin wrote:

I see everything twice:
On Fri, 4 Sep 2020 19:05:32 +, Robert Prins wrote:
On Fri, 4 Sep 2020 19:06:49 +, Robert Prins wrote:


Yes, problems posting. Should be OK now.


Your setting your system clock to Europe/Vilnius but calling it UTC
remains an irritant to those who want to read threads in chronological
sequence.  I suppose you relish your plies' floating to the top of the
list for a couple hours.


Completely oblivious of that, and definitely not to keep myself in the picture. 
The simple fact is that I hate it that 'doze displays timestamps different in 
different time zones. So my TZ is UTC.



However as a Pascal partisan, you should love(?) the NOLAXQUAL compiler option,
one of the options (when used) that takes away one of the best features of PL/I,
which is that as long as the compiler can uniquely find a variable in its symbol
table, you do not have to fully qualify it. Wit the the NOLAXQUAL compiler
option you will have to use myvar.thislevel.array.struct.variant.plorkestein,
even if "plorkestein" is the only variable in the program with that name, which
is one of the worst features of Pascal.


Can't be as bad as the lack of static initialization.


Borland introduced Typed Constants (that aren't constants at all), and that is 
now part and parcel of every Pascal compiler, including Delphi.



And somewhat mitigated by the WITH statement.


See 
 
and 




I understand that PL/I tolerates fairly arbitrary permutation of
qualifiers as long there's a unique valid depermutation.  I.e.
 struct.array[I] and strict[I].array are alternatives.  An invitation
to obscure coding.  


None of the shops I ever worked in had rules for this, I usually put the 
subscripts at the level they should be.



C is bad enough for making array[I]
equivalent to I[array].

We confronted a cadre of PL/I partisans who strenuously objected
to the NOLAXQUAL-ness of IEEE Pascal.  They reacted by providing
a standard header containing a WITH to expose the penultimate
level of every structure.  And we scrambled to revise our code
generator to fix the resulting base register exhaustion.


An optimizing compiler, and none of the Pascal ones seem to fall into that 
category, should do this automagically.


I once wrote a Pascal program to convert RTF to SCRIPT/VS.  A
co-worker enthusiastically grabbed it, only to be dismayed that I
had relied heavily on the IEEE standard file buffer that was
unsupported by the Turbo he used.  Borland boasted of the
misfeature.


You mean you used "get" and/or "put"? I've never ever used those, but Borland, 
Virtual and Free Pascal can set up buffers for files (standard 128 bytes) and in 
one of the programs I wrote to process my hitchhike data, I'm actually almost 
completely bypassing Pascal's read(ln)/write(ln) and doing everything by direct 
access of the file buffers, reading and writing them via BlockRead/Write. Works 
like a charm, and fast!


Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html

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