Re: COBOL Cowboys

[David Crayford]

On 5/10/2018 5:10 AM, Pesce, Andy wrote:

That article is just full of all the right buzzwords: "vintage programming language 
called COBOL",
"aging programming language known as COBOL" and of course my favorite  "L E G A C Y  
 S Y S T E M S"


I don't have a problem with the term "Legacy systems". That's basically 
what mainframe runs and there's nothing wrong with that.


Let's not forget that a lot of software written for Windows is now 25 
years old and is also legacy.


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

Re: COBOL Cowboys

[David L. Craig]

On 18Oct04:2011+, Rugen, Len wrote:

> Wow, a 360/91 
> https://images.techhive.com/images/idge/imported/article/itw/2014/04/04/ibm-360-600x450-100520215-orig.jpg

NASA Goddard had one in Building 1.  I believe many IBM media
shots were taken there.
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

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

Re: COBOL Cowboys

[Mike Schwab]

https://www.youtube.com/watch?v=3LkQrtCIFA4
On Thu, Oct 4, 2018 at 4:10 PM Pesce, Andy  wrote:
>
> That article is just full of all the right buzzwords: "vintage programming 
> language called COBOL",
> "aging programming language known as COBOL" and of course my favorite  "L E G 
> A C Y   S Y S T E M S"
>
>
> That reminds me of the IBM commercial, where there are all these newbies 
> talking about having a globe on the screen that they can rotate,
> and things fly across the screen.
>
> Then you have a business guy that states:   I need a customer to order a 
> part, it needs to interface with my inventory, then ship it through logistics,
> then take payment through my bank and run it through my GL showing it in my 
> accounting system so I can see the P
>
> The newbies then look at each other and say, "We don't know how to do 
> that!"...
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: COBOL Cowboys

[Bernd Oppolzer]

Some weeks ago in a meeting a co-worker told us,
that in a neighbor team they have a problem with
some "legacy" software which they don't understand any more
and needs to be replaced. The software is written in Java
and is ONE YEAR OLD.

I mentioned that our legacy software is 25+ years old, and that
we understand it very well and do maintenance to it regularly
(when new ideas come up or the users have new requirements).
Our "legacy" software is written in PL/1 and runs on the mainframe :-)

Kind regards

Bernd


Am 04.10.2018 um 23:10 schrieb Pesce, Andy:

That article is just full of all the right buzzwords: "vintage programming language 
called COBOL",
"aging programming language known as COBOL" and of course my favorite  "L E G A C Y  
 S Y S T E M S"


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

Re: Doing DR on zVM

[Neubert, Kevin]

Specifying a processor identification number with the Cpuid operand is an 
option.  See z/VM CP Planning and Administration.

That alone may work for you depending on how your specific software checks the 
processor identification number if at all.

Otherwise automatic grace periods and self-generated codes are possible, but 
more than likely codes will need to be vendor supplied for any processor or 
specific host processor.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter
Sent: Tuesday, October 2, 2018 9:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Doing DR on zVM

Hi Experts,

I would like to get your opinion on performing DR using zVM(z/OS guest) instead 
of using a Native LPARS running on z hardware.

We are monoplex shop(just one production LPAR and one Sandbox) and does 
performing DR on zVM saves any cost in terms of licensing ?

Peter

--
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: COBOL Cowboys

[Charles Mills]

How can they tell it's using COBOL from the photograph?

My wild guess is that it's in an IBM laboratory and if it is running at all, 
it's running diagnostics.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of William Donzelli
Sent: Thursday, October 4, 2018 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: COBOL Cowboys

The upper picture is a model 75.

--
Will
On Thu, Oct 4, 2018 at 3:50 PM Seymour J Metz  wrote:
>
> WTF? That doesn't look like and S/360 I've ever seen. 7030?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Jesse 1 Robinson 
> Sent: Thursday, October 4, 2018 2:34 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: COBOL Cowboys
>
> Why Westerns may ride back into town after sunset.
>
> https://secure-web.cisco.com/1K0vvSa96Cx69xdnbdpCC77e415-LO0Xuysz-y80MAiqegV0_K5NSzmfYnfnBmM46ymE_kANnak1w1THhx_2x-8_Kz2sDiI8y4H70av2RJFThvrtIXYYQu1vxWqbakdThicq_7DJugRRCxWWjWzJ0xETsY5VDwnhEmTVaMsiEZHGALiPFSkklcELK0VNO0mzKwKQtkcB4aBtuMuwrypVNyxbEUJfcAbaq3L2lqqsgTyp2ybQVuOYspSYW2Q7NsbooIrw2sNVHLWBj7OFrGQEA2ygQ2E37bdjoFJKBF34LjGL-98bkAWSDvwG2sfz0DNDnEv38PQHKbyLzF-3ayU9HdA0cBLSvCyDDZLn4aPMIGRBlDASGLZgjWHhHF76wheorSZj8t3mdV1JNt26S-3v17tYYkx07tnLzfprkC9bOGK3b3--N80dUn9gzlUxzqUDuW-334_n_bBSnv2VhBYbYKA/https%3A%2F%2Fuk.reuters.com%2Farticle%2Fuk-usa-banks-cobol-idUKKBN17C0DZ
>
> .
> .
> 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

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

Re: COBOL Cowboys

[Pesce, Andy]

That article is just full of all the right buzzwords: "vintage programming 
language called COBOL",
"aging programming language known as COBOL" and of course my favorite  "L E G A 
C Y   S Y S T E M S"


That reminds me of the IBM commercial, where there are all these newbies 
talking about having a globe on the screen that they can rotate,
and things fly across the screen.

Then you have a business guy that states:   I need a customer to order a part, 
it needs to interface with my inventory, then ship it through logistics,
then take payment through my bank and run it through my GL showing it in my 
accounting system so I can see the P

The newbies then look at each other and say, "We don't know how to do 
that!"...




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

Re: COBOL Cowboys

[William Donzelli]

The upper picture is a model 75.

--
Will
On Thu, Oct 4, 2018 at 3:50 PM Seymour J Metz  wrote:
>
> WTF? That doesn't look like and S/360 I've ever seen. 7030?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Jesse 1 Robinson 
> Sent: Thursday, October 4, 2018 2:34 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: COBOL Cowboys
>
> Why Westerns may ride back into town after sunset.
>
> https://secure-web.cisco.com/1K0vvSa96Cx69xdnbdpCC77e415-LO0Xuysz-y80MAiqegV0_K5NSzmfYnfnBmM46ymE_kANnak1w1THhx_2x-8_Kz2sDiI8y4H70av2RJFThvrtIXYYQu1vxWqbakdThicq_7DJugRRCxWWjWzJ0xETsY5VDwnhEmTVaMsiEZHGALiPFSkklcELK0VNO0mzKwKQtkcB4aBtuMuwrypVNyxbEUJfcAbaq3L2lqqsgTyp2ybQVuOYspSYW2Q7NsbooIrw2sNVHLWBj7OFrGQEA2ygQ2E37bdjoFJKBF34LjGL-98bkAWSDvwG2sfz0DNDnEv38PQHKbyLzF-3ayU9HdA0cBLSvCyDDZLn4aPMIGRBlDASGLZgjWHhHF76wheorSZj8t3mdV1JNt26S-3v17tYYkx07tnLzfprkC9bOGK3b3--N80dUn9gzlUxzqUDuW-334_n_bBSnv2VhBYbYKA/https%3A%2F%2Fuk.reuters.com%2Farticle%2Fuk-usa-banks-cobol-idUKKBN17C0DZ
>
> .
> .
> 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: COBOL Cowboys

[Rugen, Len]

Wow, a 360/91 
https://images.techhive.com/images/idge/imported/article/itw/2014/04/04/ibm-360-600x450-100520215-orig.jpg

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

Re: COBOL Cowboys

[Rugen, Len]

Yea, it looks like it's way too wide, but I think they made some odd "one off" 
or small batch 360's. 

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

Re: COBOL Cowboys

[Seymour J Metz]

WTF? That doesn't look like and S/360 I've ever seen. 7030?


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


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Thursday, October 4, 2018 2:34 PM
To: IBM-MAIN@listserv.ua.edu
Subject: COBOL Cowboys

Why Westerns may ride back into town after sunset.

https://secure-web.cisco.com/1K0vvSa96Cx69xdnbdpCC77e415-LO0Xuysz-y80MAiqegV0_K5NSzmfYnfnBmM46ymE_kANnak1w1THhx_2x-8_Kz2sDiI8y4H70av2RJFThvrtIXYYQu1vxWqbakdThicq_7DJugRRCxWWjWzJ0xETsY5VDwnhEmTVaMsiEZHGALiPFSkklcELK0VNO0mzKwKQtkcB4aBtuMuwrypVNyxbEUJfcAbaq3L2lqqsgTyp2ybQVuOYspSYW2Q7NsbooIrw2sNVHLWBj7OFrGQEA2ygQ2E37bdjoFJKBF34LjGL-98bkAWSDvwG2sfz0DNDnEv38PQHKbyLzF-3ayU9HdA0cBLSvCyDDZLn4aPMIGRBlDASGLZgjWHhHF76wheorSZj8t3mdV1JNt26S-3v17tYYkx07tnLzfprkC9bOGK3b3--N80dUn9gzlUxzqUDuW-334_n_bBSnv2VhBYbYKA/https%3A%2F%2Fuk.reuters.com%2Farticle%2Fuk-usa-banks-cobol-idUKKBN17C0DZ

.
.
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: Looking for an appropriate system exit

[Tony Harminc]

On 4 October 2018 at 12:56, Charles Mills  wrote:
> The dynamic exits facility does a pretty much perfect job of isolating 
> various exit routines one from another.

I agree with Charles - it's a great facility with about all the power
and convenience one could ask for. (Now why certain IBM components
continue not to use it is another matter.)

Steff Gladstone wrote:
[...]
> (or issue the equivalent CSVDYNEX macro in an assembler program) to add our
> exit routines to the system exit points SYS.IEFUSI AND SYS.IEFACTRT,
[...]

I would just watch for two possible trouble areas:

Will either or both exits get control where you don't expect it, e.g.
for things other than batch jobs/steps? Your code may need to be aware
of its invocation environment that could be TSO, a
forked/spawned/exec'd UNIX job step, or an APPC transaction. Maybe you
don't have any of these, but your code should probably be aware and
ignore them gracefully if you don't want to process them.

On the flip side, dynamically adding exit routines to SYS.xxx may not
be enough to capture everything of interest. If it's your own system
and you know what your SMFPRMxx looks like, then fine. But depending
on the SYS and SUBSYS parameters, there could be exit points for
things like TSO.xxx or IMS.yyy or ASCH.zzz. Best generalized approach
if you're going to use CSVDYNEX is to issue CSVDYNEX  REQUEST=LIST,
and then scan the result for exit point names *ending* in .IEFUSI and
.IEFACTRT (noting that the left parts can be of different lengths). Or
of course just hard code what you know you need.

And it goes without saying that these exits run in the most highly
privileged state possible, i.e. key zero and supervisor state. So code
and test very carefully...

Tony H.

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

Re: COBOL Cowboys

[Paul Gilmartin]

On Thu, 4 Oct 2018 18:34:13 +, Jesse 1 Robinson wrote:

>Why Westerns may ride back into town after sunset.
>
>https://uk.reuters.com/article/uk-usa-banks-cobol-idUKKBN17C0DZ
>...
The industry appears to be reaching an inflection point, though.
In the United States, banks are slowly shifting towards newer 
languages taking cue from overseas rivals who have already 
made the switch-over. 
...
No.  History repeats itself.  When Java, Python, ... are replaced by yet
more stylish languages the problem will recur.  But it won't matter to
you and me.

Perhaps by then AI will have advanced to where the programs will write
themselves.  But will they be ethical?  "Trusting Trust".  "Paperclip 
Optimizer". ...

-- gil

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

Re: COBOL Cowboys

[John McKown]

On Thu, Oct 4, 2018 at 2:05 PM Longabaugh, Robert E <
robert.longaba...@ca.com> wrote:

> Big mistake in this article where they say IBM "makes the computers that
> run on COBOL".  This should be "makes the computers that run COBOL
> programs".  I can't find a place to comment or email the author.
>

Right! Everybody knows that computers run on B.S. (not Bachelor of
Science!). That's why I.T. management is so full of it.



>
> Bob Longabaugh
> CA Technologies
> Storage Management
>
>
-- 
People who frustrate us will be around for as long as we need them.

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: COBOL Cowboys

[Longabaugh, Robert E]

Big mistake in this article where they say IBM "makes the computers that run on 
COBOL".  This should be "makes the computers that run COBOL programs".  I can't 
find a place to comment or email the author.

Bob Longabaugh
CA Technologies
Storage Management 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jesse 1 Robinson
Sent: Thursday, October 04, 2018 1:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: COBOL Cowboys

CAUTION: This email originated from outside of CA. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


Why Westerns may ride back into town after sunset.

https://urldefense.proofpoint.com/v2/url?u=https-3A__uk.reuters.com_article_uk-2Dusa-2Dbanks-2Dcobol-2DidUKKBN17C0DZ=DwIFAg=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0=_pjUpH7SxKBkB6gBZH_r7a7W1q59Nzy5lPxFUOMH-UM=wioJ6rDoqUpds6uGjH6r_Z3GUz7TN2PJYcmnCat8zyo=QMXTjUOmnw3Sv_oCDwfbhwWHAkgsW2b5Rd7VKU1Ftu0=

.
.
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

COBOL Cowboys

[Jesse 1 Robinson]

Why Westerns may ride back into town after sunset.

https://uk.reuters.com/article/uk-usa-banks-cobol-idUKKBN17C0DZ

.
.
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

Re: SYSRES Volume Size (Was: S106 abends ...)

[Jousma, David]

Just to expand on this a bit.  I have all mod-54 sysres volumes that we rotate 
through. It’s the quantity of ZFS that has blown that out:

ZFS - 398454 tracks
Traditional - ~150K tracks.



-Original Message-
From: Jousma, David 
Sent: Thursday, October 04, 2018 1:00 PM
To: 'IBM Mainframe Discussion List' 
Subject: RE: SYSRES Volume Size (Was: S106 abends ...)

Mod-54.   70+% utilized.   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Thursday, October 04, 2018 12:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SYSRES Volume Size (Was: S106 abends ...)

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

What size SYSRES do most shops use these days?

We have settled on Mod-27 as our "standard" volume for almost everything. We 
also have some Mod-9s and Mod-216s for special purposes.

No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just the 
three described above...

On 10/4/2018 8:26 AM, Jesse 1 Robinson wrote:
> I sympathize with IBM's predicament in reading the future maintenance tea 
> leaves. The 'fix rate' for a product might be subject to guesstimation from 
> past experience. But the effects of future enhancements like SPEs and 
> customer requirements are a bundle of uncertainties wrapped in unknowns. The 
> change from six month to two year release cycles further clouded space 
> predictions.
>
> I think customers are best off expecting data set expansions. A few like 
> LINKLIB and LPALIB can be deliberately oversized as likely candidates for 
> increase in a variety of components. But the migratable sysres volume is 
> limited to whatever size installation has settled on. Secondary extents, in 
> my view, allow for unpredictable expansion with acceptable risk.
>
> .
> .
> 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John Eells
> Sent: Thursday, October 04, 2018 4:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: S106 abends after copying into LINKLIST
>
> Elardus Engelbrecht wrote:
>
>> This is why you see in Program Directories the required space for each 
>> dataset/OMVS files needed for each product you ordered.
> Let's just be clear about what those space numbers represent.
>
> They are:
>
> - a fixed percentage larger (10 or 15%, I forget right now) than the 
> amount of space consumed by each data set at a particular point in 
> time
> - are measured at the specified block sizes when the FMIDs represented 
> by that program directory were submitted to software manufacturing and 
> never updated
> - provide information for only that product and no others that might share 
> the data set.
>
> So if PTFs cause the space required to grow by more than the fixed 
> percentage, or you use different block sizes than we specify (which is not to 
> your advantage in general), or fail to add the space required by all products 
> sharing a data set together, you will be in x37 City before you know it.
>
> ServerPac production is smart enough to adjust space on the fly, BTW, so the 
> free space allocated by default stays at a fixed percentage even as PTFs 
> consume more space in the data sets for the products included.  For CBPDO, 
> you get to guess yourself.
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com



This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole use of the intended 
recipient(s). If you are not an intended recipient or have otherwise received 
this email message in error, any use, dissemination, distribution, review, 
storage or copying of this e-mail message and the information contained therein 
is strictly prohibited. If you are not an intended recipient, please contact 
the sender by reply e-mail and destroy all copies of this email message and do 
not otherwise utilize or retain this email message or any or all of the 
information contained therein. Although this email message and any attachments 
or appended messages are believed to be free of any virus or other defect that 
might affect any computer system into which it is received and opened, it is 
the responsibility of the recipient to ensure that it is virus free and no 
responsibility is accepted by the sender for any loss or damage arising in any 
way from its opening or use.

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

**DO NOT open attachments or click on links from 

Chinese Hack Servers with Microchip.(Bloomberg)

[Edward Finnell]

https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
They probably aren't the only ones.

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

Re: SYSRES Volume Size (Was: S106 abends ...)

[Carmen Vitullo]

Our last tech (DASD) refresh from 100% mod-54 



Carmen Vitullo 

- Original Message -

From: "Ed Jaffe"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, October 4, 2018 11:15:46 AM 
Subject: SYSRES Volume Size (Was: S106 abends ...) 

What size SYSRES do most shops use these days? 

We have settled on Mod-27 as our "standard" volume for almost 
everything. We also have some Mod-9s and Mod-216s for special purposes. 

No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just 
the three described above... 

On 10/4/2018 8:26 AM, Jesse 1 Robinson wrote: 
> I sympathize with IBM's predicament in reading the future maintenance tea 
> leaves. The 'fix rate' for a product might be subject to guesstimation from 
> past experience. But the effects of future enhancements like SPEs and 
> customer requirements are a bundle of uncertainties wrapped in unknowns. The 
> change from six month to two year release cycles further clouded space 
> predictions. 
> 
> I think customers are best off expecting data set expansions. A few like 
> LINKLIB and LPALIB can be deliberately oversized as likely candidates for 
> increase in a variety of components. But the migratable sysres volume is 
> limited to whatever size installation has settled on. Secondary extents, in 
> my view, allow for unpredictable expansion with acceptable risk. 
> 
> . 
> . 
> 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of John Eells 
> Sent: Thursday, October 04, 2018 4:35 AM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: (External):Re: S106 abends after copying into LINKLIST 
> 
> Elardus Engelbrecht wrote: 
> 
>> This is why you see in Program Directories the required space for each 
>> dataset/OMVS files needed for each product you ordered. 
> Let's just be clear about what those space numbers represent. 
> 
> They are: 
> 
> - a fixed percentage larger (10 or 15%, I forget right now) than the amount 
> of space consumed by each data set at a particular point in time 
> - are measured at the specified block sizes when the FMIDs represented by 
> that program directory were submitted to software manufacturing and never 
> updated 
> - provide information for only that product and no others that might share 
> the data set. 
> 
> So if PTFs cause the space required to grow by more than the fixed 
> percentage, or you use different block sizes than we specify (which is not to 
> your advantage in general), or fail to add the space required by all products 
> sharing a data set together, you will be in x37 City before you know it. 
> 
> ServerPac production is smart enough to adjust space on the fly, BTW, so the 
> free space allocated by default stays at a fixed percentage even as PTFs 
> consume more space in the data sets for the products included. For CBPDO, you 
> get to guess yourself. 
> 
> -- 
> John Eells 
> IBM Poughkeepsie 
> ee...@us.ibm.com 



 
This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole use of the intended 
recipient(s). If you are not an intended recipient or have otherwise 
received this email message in error, any use, dissemination, distribution, 
review, storage or copying of this e-mail message and the information 
contained therein is strictly prohibited. If you are not an intended 
recipient, please contact the sender by reply e-mail and destroy all copies 
of this email message and do not otherwise utilize or retain this email 
message or any or all of the information contained therein. Although this 
email message and any attachments or appended messages are believed to be 
free of any virus or other defect that might affect any computer system into 
which it is received and opened, it is the responsibility of the recipient 
to ensure that it is virus free and no responsibility is accepted by the 
sender for any loss or damage arising in any way from its opening or use. 

-- 
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: [External] SYSRES Volume Size (Was: S106 abends ...)

[Pommier, Rex]

SYSRES are 27s.   Still using primarily 9s for other stuff but gradually moving 
to 27s.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Thursday, October 04, 2018 11:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] SYSRES Volume Size (Was: S106 abends ...)

What size SYSRES do most shops use these days?

We have settled on Mod-27 as our "standard" volume for almost 
everything. We also have some Mod-9s and Mod-216s for special purposes.

No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just 
the three described above...

On 10/4/2018 8:26 AM, Jesse 1 Robinson wrote:
> I sympathize with IBM's predicament in reading the future maintenance tea 
> leaves. The 'fix rate' for a product might be subject to guesstimation from 
> past experience. But the effects of future enhancements like SPEs and 
> customer requirements are a bundle of uncertainties wrapped in unknowns. The 
> change from six month to two year release cycles further clouded space 
> predictions.
>
> I think customers are best off expecting data set expansions. A few like 
> LINKLIB and LPALIB can be deliberately oversized as likely candidates for 
> increase in a variety of components. But the migratable sysres volume is 
> limited to whatever size installation has settled on. Secondary extents, in 
> my view, allow for unpredictable expansion with acceptable risk.
>
> .
> .
> 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of John Eells
> Sent: Thursday, October 04, 2018 4:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: S106 abends after copying into LINKLIST
>
> Elardus Engelbrecht wrote:
>
>> This is why you see in Program Directories the required space for each 
>> dataset/OMVS files needed for each product you ordered.
> Let's just be clear about what those space numbers represent.
>
> They are:
>
> - a fixed percentage larger (10 or 15%, I forget right now) than the amount 
> of space consumed by each data set at a particular point in time
> - are measured at the specified block sizes when the FMIDs represented by 
> that program directory were submitted to software manufacturing and never 
> updated
> - provide information for only that product and no others that might share 
> the data set.
>
> So if PTFs cause the space required to grow by more than the fixed 
> percentage, or you use different block sizes than we specify (which is not to 
> your advantage in general), or fail to add the space required by all products 
> sharing a data set together, you will be in x37 City before you know it.
>
> ServerPac production is smart enough to adjust space on the fly, BTW, so the 
> free space allocated by default stays at a fixed percentage even as PTFs 
> consume more space in the data sets for the products included.  For CBPDO, 
> you get to guess yourself.
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 

Re: SDSF on batch problem

[Paul Gilmartin]

On Thu, 4 Oct 2018 10:12:29 -0700, retired mainframer wrote:

>...  Does the batch job name start with the TSO user name?
>
How much does this matter nowadays?  I've rarely bothered with it.
Would it matter how many additional characters in the suffix?

>> -Original Message-
>> From:  Hilario Garcia
>> Sent: Thursday, October 04, 2018 4:50 AM
>> 
>> The installation use RACF. I had test to use IKJEFT01 and call SDSF on
>> batch and I have the same problema.
>> 
>> I don't have why use different GRPNAME in online and batch.

-- gil

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

Re: SDSF on batch problem

[retired mainframer]

Do the batch job and TSO user run under the same RACF user name and group?  
Does the batch job name start with the TSO user name?

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Hilario Garcia
> Sent: Thursday, October 04, 2018 4:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SDSF on batch problem
> 
> Hello ITschak,
> 
> The installation use RACF. I had test to use IKJEFT01 and call SDSF on
> batch and I have the same problema.
> 
> I don't have why use different GRPNAME in online and batch.

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

Re: SYSRES Volume Size (Was: S106 abends ...)

[Jousma, David]

Mod-54.   70+% utilized.   

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Thursday, October 04, 2018 12:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SYSRES Volume Size (Was: S106 abends ...)

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

What size SYSRES do most shops use these days?

We have settled on Mod-27 as our "standard" volume for almost everything. We 
also have some Mod-9s and Mod-216s for special purposes.

No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just the 
three described above...

On 10/4/2018 8:26 AM, Jesse 1 Robinson wrote:
> I sympathize with IBM's predicament in reading the future maintenance tea 
> leaves. The 'fix rate' for a product might be subject to guesstimation from 
> past experience. But the effects of future enhancements like SPEs and 
> customer requirements are a bundle of uncertainties wrapped in unknowns. The 
> change from six month to two year release cycles further clouded space 
> predictions.
>
> I think customers are best off expecting data set expansions. A few like 
> LINKLIB and LPALIB can be deliberately oversized as likely candidates for 
> increase in a variety of components. But the migratable sysres volume is 
> limited to whatever size installation has settled on. Secondary extents, in 
> my view, allow for unpredictable expansion with acceptable risk.
>
> .
> .
> 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John Eells
> Sent: Thursday, October 04, 2018 4:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: S106 abends after copying into LINKLIST
>
> Elardus Engelbrecht wrote:
>
>> This is why you see in Program Directories the required space for each 
>> dataset/OMVS files needed for each product you ordered.
> Let's just be clear about what those space numbers represent.
>
> They are:
>
> - a fixed percentage larger (10 or 15%, I forget right now) than the 
> amount of space consumed by each data set at a particular point in 
> time
> - are measured at the specified block sizes when the FMIDs represented 
> by that program directory were submitted to software manufacturing and 
> never updated
> - provide information for only that product and no others that might share 
> the data set.
>
> So if PTFs cause the space required to grow by more than the fixed 
> percentage, or you use different block sizes than we specify (which is not to 
> your advantage in general), or fail to add the space required by all products 
> sharing a data set together, you will be in x37 City before you know it.
>
> ServerPac production is smart enough to adjust space on the fly, BTW, so the 
> free space allocated by default stays at a fixed percentage even as PTFs 
> consume more space in the data sets for the products included.  For CBPDO, 
> you get to guess yourself.
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com



This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole use of the intended 
recipient(s). If you are not an intended recipient or have otherwise received 
this email message in error, any use, dissemination, distribution, review, 
storage or copying of this e-mail message and the information contained therein 
is strictly prohibited. If you are not an intended recipient, please contact 
the sender by reply e-mail and destroy all copies of this email message and do 
not otherwise utilize or retain this email message or any or all of the 
information contained therein. Although this email message and any attachments 
or appended messages are believed to be free of any virus or other defect that 
might affect any computer system into which it is received and opened, it is 
the responsibility of the recipient to ensure that it is virus free and no 
responsibility is accepted by the sender for any loss or damage arising in any 
way from its opening or use.

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of 

Re: Looking for an appropriate system exit

[Charles Mills]

The dynamic exits facility does a pretty much perfect job of isolating various 
exit routines one from another.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steff Gladstone
Sent: Thursday, October 4, 2018 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for an appropriate system exit

After a respite of several months this topic has gotten  hot again for us.
We believe that using the IEFUSI and IEFACTRT exits answer our need to gain
control at job-step initialization and again at job-step termination.

My question is:  if we use the dynamic exits facility, that is, the console
command

   SETPROG EXIT,ADD,EX=,MOD=,LAST

(or issue the equivalent CSVDYNEX macro in an assembler program) to add our
exit routines to the system exit points SYS.IEFUSI AND SYS.IEFACTRT, and
assuming we are careful to return R15=0 in our exit routines and not change
anything in the passed parameters, could that still affect or override in
any way the results of the default or system exit routines already in
effect for those exit points?   We would like our exits to be as innocuous
as possible and not adversely affect what is already in the system.

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

Re: SYSRES Volume Size (Was: S106 abends ...)

[Feller, Paul]

All of our SYSRES (and DLIB) volumes are MOD-27.  We even have our rescue (1 
pack) system back to a true 1 pack on a MOD-27.

As for the other stuff we have very few MOD-1 and MOD-3 volumes.  Mainly MOD-9, 
MOD-27, MOD-54 and 3 EAV volumes.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Thursday, October 04, 2018 11:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SYSRES Volume Size (Was: S106 abends ...)

What size SYSRES do most shops use these days?

We have settled on Mod-27 as our "standard" volume for almost everything. We 
also have some Mod-9s and Mod-216s for special purposes.

No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just the 
three described above...

On 10/4/2018 8:26 AM, Jesse 1 Robinson wrote:
> I sympathize with IBM's predicament in reading the future maintenance tea 
> leaves. The 'fix rate' for a product might be subject to guesstimation from 
> past experience. But the effects of future enhancements like SPEs and 
> customer requirements are a bundle of uncertainties wrapped in unknowns. The 
> change from six month to two year release cycles further clouded space 
> predictions.
>
> I think customers are best off expecting data set expansions. A few like 
> LINKLIB and LPALIB can be deliberately oversized as likely candidates for 
> increase in a variety of components. But the migratable sysres volume is 
> limited to whatever size installation has settled on. Secondary extents, in 
> my view, allow for unpredictable expansion with acceptable risk.
>
> .
> .
> 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John Eells
> Sent: Thursday, October 04, 2018 4:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: S106 abends after copying into LINKLIST
>
> Elardus Engelbrecht wrote:
>
>> This is why you see in Program Directories the required space for each 
>> dataset/OMVS files needed for each product you ordered.
> Let's just be clear about what those space numbers represent.
>
> They are:
>
> - a fixed percentage larger (10 or 15%, I forget right now) than the 
> amount of space consumed by each data set at a particular point in 
> time
> - are measured at the specified block sizes when the FMIDs represented 
> by that program directory were submitted to software manufacturing and 
> never updated
> - provide information for only that product and no others that might share 
> the data set.
>
> So if PTFs cause the space required to grow by more than the fixed 
> percentage, or you use different block sizes than we specify (which is not to 
> your advantage in general), or fail to add the space required by all products 
> sharing a data set together, you will be in x37 City before you know it.
>
> ServerPac production is smart enough to adjust space on the fly, BTW, so the 
> free space allocated by default stays at a fixed percentage even as PTFs 
> consume more space in the data sets for the products included.  For CBPDO, 
> you get to guess yourself.
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com



This e-mail message, including any attachments, appended messages and the 
information contained therein, is for the sole use of the intended 
recipient(s). If you are not an intended recipient or have otherwise received 
this email message in error, any use, dissemination, distribution, review, 
storage or copying of this e-mail message and the information contained therein 
is strictly prohibited. If you are not an intended recipient, please contact 
the sender by reply e-mail and destroy all copies of this email message and do 
not otherwise utilize or retain this email message or any or all of the 
information contained therein. Although this email message and any attachments 
or appended messages are believed to be free of any virus or other defect that 
might affect any computer system into which it is received and opened, it is 
the responsibility of the recipient to ensure that it is virus free and no 
responsibility is accepted by the sender for any loss or damage arising in any 
way from its opening or use.

--
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: SYSRES Volume Size (Was: S106 abends ...)

[Pew, Curtis G]

On Oct 4, 2018, at 11:15 AM, Ed Jaffe  wrote:
> 
> What size SYSRES do most shops use these days?
> 
> We have settled on Mod-27 as our "standard" volume for almost everything. We 
> also have some Mod-9s and Mod-216s for special purposes.
> 
> No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just the 
> three described above...
> 

All our volumes are configured as mod-54s. We also use thin provisioning; our 
defined volumes are about 135% of the physically available space, but only 
about 70% of that space is actually in use.

I would never want to go back to not using thin provisioning.


-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services

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

SYSRES Volume Size (Was: S106 abends ...)

[Ed Jaffe]

What size SYSRES do most shops use these days?

We have settled on Mod-27 as our "standard" volume for almost 
everything. We also have some Mod-9s and Mod-216s for special purposes.


No Mod-1s, Mod-2s, Mod-3s, Mod-54s, or any other "oddball" sizes. Just 
the three described above...


On 10/4/2018 8:26 AM, Jesse 1 Robinson wrote:

I sympathize with IBM's predicament in reading the future maintenance tea 
leaves. The 'fix rate' for a product might be subject to guesstimation from 
past experience. But the effects of future enhancements like SPEs and customer 
requirements are a bundle of uncertainties wrapped in unknowns. The change from 
six month to two year release cycles further clouded space predictions.

I think customers are best off expecting data set expansions. A few like 
LINKLIB and LPALIB can be deliberately oversized as likely candidates for 
increase in a variety of components. But the migratable sysres volume is 
limited to whatever size installation has settled on. Secondary extents, in my 
view, allow for unpredictable expansion with acceptable risk.

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Thursday, October 04, 2018 4:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: S106 abends after copying into LINKLIST

Elardus Engelbrecht wrote:


This is why you see in Program Directories the required space for each 
dataset/OMVS files needed for each product you ordered.

Let's just be clear about what those space numbers represent.

They are:

- a fixed percentage larger (10 or 15%, I forget right now) than the amount of 
space consumed by each data set at a particular point in time
- are measured at the specified block sizes when the FMIDs represented by that 
program directory were submitted to software manufacturing and never updated
- provide information for only that product and no others that might share the 
data set.

So if PTFs cause the space required to grow by more than the fixed percentage, 
or you use different block sizes than we specify (which is not to your 
advantage in general), or fail to add the space required by all products 
sharing a data set together, you will be in x37 City before you know it.

ServerPac production is smart enough to adjust space on the fly, BTW, so the 
free space allocated by default stays at a fixed percentage even as PTFs 
consume more space in the data sets for the products included.  For CBPDO, you 
get to guess yourself.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com




This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: S106 abends after copying into LINKLIST

[Jesse 1 Robinson]

I sympathize with IBM's predicament in reading the future maintenance tea 
leaves. The 'fix rate' for a product might be subject to guesstimation from 
past experience. But the effects of future enhancements like SPEs and customer 
requirements are a bundle of uncertainties wrapped in unknowns. The change from 
six month to two year release cycles further clouded space predictions. 

I think customers are best off expecting data set expansions. A few like 
LINKLIB and LPALIB can be deliberately oversized as likely candidates for 
increase in a variety of components. But the migratable sysres volume is 
limited to whatever size installation has settled on. Secondary extents, in my 
view, allow for unpredictable expansion with acceptable risk. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Thursday, October 04, 2018 4:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: S106 abends after copying into LINKLIST

Elardus Engelbrecht wrote:

> This is why you see in Program Directories the required space for each 
> dataset/OMVS files needed for each product you ordered.

Let's just be clear about what those space numbers represent.

They are:

- a fixed percentage larger (10 or 15%, I forget right now) than the amount of 
space consumed by each data set at a particular point in time
- are measured at the specified block sizes when the FMIDs represented by that 
program directory were submitted to software manufacturing and never updated
- provide information for only that product and no others that might share the 
data set.

So if PTFs cause the space required to grow by more than the fixed percentage, 
or you use different block sizes than we specify (which is not to your 
advantage in general), or fail to add the space required by all products 
sharing a data set together, you will be in x37 City before you know it.

ServerPac production is smart enough to adjust space on the fly, BTW, so the 
free space allocated by default stays at a fixed percentage even as PTFs 
consume more space in the data sets for the products included.  For CBPDO, you 
get to guess yourself.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com


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

Re: Looking for an appropriate system exit

[Steff Gladstone]

After a respite of several months this topic has gotten  hot again for us.
We believe that using the IEFUSI and IEFACTRT exits answer our need to gain
control at job-step initialization and again at job-step termination.

My question is:  if we use the dynamic exits facility, that is, the console
command

   SETPROG EXIT,ADD,EX=,MOD=,LAST

(or issue the equivalent CSVDYNEX macro in an assembler program) to add our
exit routines to the system exit points SYS.IEFUSI AND SYS.IEFACTRT, and
assuming we are careful to return R15=0 in our exit routines and not change
anything in the passed parameters, could that still affect or override in
any way the results of the default or system exit routines already in
effect for those exit points?   We would like our exits to be as innocuous
as possible and not adversely affect what is already in the system.

On 8 December 2017 at 15:47, Binyamin Dissen 
wrote:

>
> Your best/easiest would be a SAF exit for checking PROGRAM class - that
> gets
> control for each load without hooking stuff. Otherwise you can hook the
> standard LOAD/LINK/ATTACH SVCs.  The IEFUSI would have the EXEC PGM= name.
>
> On Wed, 6 Dec 2017 12:14:45 +0200 Steff Gladstone <
> steff.gladst...@gmail.com>
> wrote:
>
> :>Hi Binyamin,
> :>
> :>The application load libraries are full of obsolete code.  We are trying
> to
> :>identify which programs are still active in the installation in order to
> :>weed out obsolete legacy programs and clean up our load libraries, and
> :>eventually, source libraries.
> :>
> :>We were hoping to choose an optimal exit that would enable us to capture
> :>pertinent info: called load module name, load library name, caller name,
> :>etc.  We would prefer an exit that allows the designation of a number of
> :>individual exit routines per exit (JES2 and CICS and, to a limited
> extent,
> :>DFSMS, provide this capability; I am not aware of other possibilities),
> so
> :>that we could easily disable or remove our code when necessary without
> :>affecting other customized user code in that exit.
> :>
> :>Thanks for any assistance you can extend to us.
> :>
> :>Steff Gladstone
> :>
> :>On Wed, Dec 6, 2017 at 10:53 AM, Binyamin Dissen <
> bdis...@dissensoftware.com
> :>> wrote:
> :>
> :>> Can you give an example or two?
> :>>
> :>> On Wed, 6 Dec 2017 09:13:47 +0200 Steff Gladstone <
> :>> steff.gladst...@gmail.com>
> :>> wrote:
> :>>
> :>> :>In our installation we would like to implement certain checks and
> :>> document
> :>> :>certain run-time characteristics at the beginning and during  program
> :>> :>initialization and duration (chiefly Cobol programs).  We would like
> to
> :>> :>implement this in a manner transparent to the application, without
> :>> :>requiring the programmer to add lines of JCL or calls to subroutines
> (we
> :>> :>have thousands of legacy programs and jobs and don't want to have to
> go
> :>> :>through a massive conversion project).
> :>>
> :>> :>We are looking at initialization routines like CEEBINT.   Can anyone
> :>> :>recommend any other system exits that could be candidates for this
> sort
> :>> of
> :>> :>thing.  Any potential pitfalls we should be aware of?
> :>>
> :>> --
> :>> Binyamin Dissen 
> :>> http://www.dissensoftware.com
> :>>
> :>> Director, Dissen Software, Bar & Grill - Israel
> :>>
> :>>
> :>> Should you use the mailblocks package and expect a response from me,
> :>> you should preauthorize the dissensoftware.com domain.
> :>>
> :>> I very rarely bother responding to challenge/response systems,
> :>> especially those from irresponsible companies.
> :>>
> :>> --
> :>> For IBM-MAIN subscribe / signoff / archive access instructions,
> :>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> :>>
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>

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

Crypto Utilization Question

[Richards, Robert B.]

I sent an email to Greg Boyd (Greg Boyd 
gregb...@mainframecrypto.com) asking for a 
response to a coworker's question below. In case Greg is otherwise engaged, I 
am casting a wider net to get an answer in a timely fashion (i.e. ASAP :)).

Any takers?

Thanks in advance,

Bob

The question:

We currently have a total of 3 Crypto Express4 Accelerators and 3 Crypto 
Express4 CCA coprocessors configured and shared with all of our 8 z/OS LPARS 
and 1 Crypto Express4 CCA coprocessor defined to z/VM for Linux.  We need to 
understand what utilization should be allowed for each of these to help us 
determine if we have too many or when we should be getting additional.


CRYPTOSERIAL
FEATURE   NUMBERSTATUSAES   DES   ECC   RSA   P11
---       ---   ---   ---   ---   ---
  4C00  Active A A I A
  4A01N/A   Active
  4C02  Active A A I A
  4A03N/A   Active
  4C04  Active A A I A
  4A05N/A   Active



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

Today's development methodology

[John McKown]

Or "why can't I get to my banking web site?"

https://xkcd.com/2054/

-- 
People who frustrate us will be around for as long as we need them.

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: SDSF on batch problem

[Hilario Garcia]

Hello ITschak,

The installation use RACF. I had test to use IKJEFT01 and call SDSF on
batch and I have the same problema.

I don't have why use different GRPNAME in online and batch.

Thanks in advance.

Hilario

El jue., 4 oct. 2018 a las 12:51, ITschak Mugzach ()
escribió:

> Sdsf group assignment depends on many factors like tso orocname, tso auth
> and others. Sdsf also asignes the first group that match your user id, so
> the order of grouos is also important. I assume you are not usinf saf
> (racf, tss, etc.) For group assignment.
>
> ITschak
>
> בתאריך יום ה׳, 4 באוק׳ 2018, 12:26, מאת Hilario Garcia ‏ >:
>
> > Hello,
> >
> > Checking was performed using the OMS command of the SDSF and I assigned a
> > different GRPNAME for a different TSO session to a SDSF session in batch.
> > Under TSO, I am assigned the profile of ISFPRM00 as a system programmer
> and
> > under SDSF in batch that of a normal user.
> >
> > Can someone tell me how I can modify the GRPNAME assignment for batch
> > processes executed by a systems programmer?
> >
> > Thank you very much in advance. Hilario
> >
> > El mié., 3 oct. 2018 a las 12:22, ITschak Mugzach ()
> > escribió:
> >
> > > Try print the who command on both environments and compare the sdsf
> group
> > > first.
> > >
> > > ITschak
> > >
> > > בתאריך יום ד׳, 3 באוק׳ 2018, 8:56, מאת Hilario Garcia ‏<
> > libr...@gmail.com
> > > >:
> > >
> > > > Hello,
> > > >
> > > > I have an LPAR that when we access through a session of "TSO" to the
> > SDSF
> > > > allows me a series of options.
> > > >
> > > > If you access the SDSF through a batch process, the options that
> allow
> > me
> > > > to visualize the SDSF are different.
> > > >
> > > > In both situation the userid is the same
> > > >
> > > > Attached documentation of the problem.
> > > >
> > > > Thank you very much in advance.
> > > >
> > > > Hilario
> > > >
> > > > - Options from a TSO session
> > > >
> > > >  COMMAND INPUT ===>
> > > >
> > > >  DAActive users  INIT  Initiators
> > > >  I Input queue   PRPrinters
> > > >  O Output queue  PUN   Punches
> > > >  H Held output queue RDR   Readers
> > > >  STStatus of jobsLINE  Lines
> > > >  NODE  Nodes
> > > >  LOG   System logSOSpool offload
> > > >  MAS   Members in the MAS
> > > >  JCJob classes   ULOG  User session log
> > > >  SEScheduling environments
> > > >  RES   WLM resources
> > > >
> > > >  END   Exit SDSF
> > > >
> > > > - Options from a batch session
> > > > COMMAND INPUT ===>
> > > >
> > > > DAActive users
> > > > I Input queue
> > > > O Output queue
> > > > H Held output queue
> > > > STStatus of jobs
> > > >
> > > > SEScheduling environments
> > > >
> > > > END   Exit SDSF
> > > >
> > > > - JCL used on batch
> > > >
> > > > //SDSFSTEP EXEC PGM=SDSF,PARM='++60,228'
> > > > //ISFOUT DD SYSOUT=*
> > > > //SYSPRINT DD SYSOUT=*
> > > > //SYSOUTDD SYSOUT=*
> > > > //ISFIN   DD *
> > > > PRINT ODSN '.LST(JOBLOG)'
> > > > PREFIX *
> > > > OWNER *
> > > > ST SDSFBAT
> > > > ++ALL
> > > > FIND SDSFBAT
> > > > ++//X
> > > > FIND SDSFBAT  LAST
> > > > ++//
> > > > PRINT
> > > > PRINT CLOSE
> > > > END
> > > >
> > > > Hilario
> > > >
> > > >
> --
> > > > 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
>

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

Re: S106 abends after copying into LINKLIST

[John Eells]

Elardus Engelbrecht wrote:


This is why you see in Program Directories the required space for each 
dataset/OMVS files needed for each product you ordered.


Let's just be clear about what those space numbers represent.

They are:

- a fixed percentage larger (10 or 15%, I forget right now) than the 
amount of space consumed by each data set at a particular point in time
- are measured at the specified block sizes when the FMIDs represented 
by that program directory were submitted to software manufacturing and 
never updated
- provide information for only that product and no others that might 
share the data set.


So if PTFs cause the space required to grow by more than the fixed 
percentage, or you use different block sizes than we specify (which is 
not to your advantage in general), or fail to add the space required by 
all products sharing a data set together, you will be in x37 City before 
you know it.


ServerPac production is smart enough to adjust space on the fly, BTW, so 
the free space allocated by default stays at a fixed percentage even as 
PTFs consume more space in the data sets for the products included.  For 
CBPDO, you get to guess yourself.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: SDSF on batch problem

[ITschak Mugzach]

Sdsf group assignment depends on many factors like tso orocname, tso auth
and others. Sdsf also asignes the first group that match your user id, so
the order of grouos is also important. I assume you are not usinf saf
(racf, tss, etc.) For group assignment.

ITschak

בתאריך יום ה׳, 4 באוק׳ 2018, 12:26, מאת Hilario Garcia ‏:

> Hello,
>
> Checking was performed using the OMS command of the SDSF and I assigned a
> different GRPNAME for a different TSO session to a SDSF session in batch.
> Under TSO, I am assigned the profile of ISFPRM00 as a system programmer and
> under SDSF in batch that of a normal user.
>
> Can someone tell me how I can modify the GRPNAME assignment for batch
> processes executed by a systems programmer?
>
> Thank you very much in advance. Hilario
>
> El mié., 3 oct. 2018 a las 12:22, ITschak Mugzach ()
> escribió:
>
> > Try print the who command on both environments and compare the sdsf group
> > first.
> >
> > ITschak
> >
> > בתאריך יום ד׳, 3 באוק׳ 2018, 8:56, מאת Hilario Garcia ‏<
> libr...@gmail.com
> > >:
> >
> > > Hello,
> > >
> > > I have an LPAR that when we access through a session of "TSO" to the
> SDSF
> > > allows me a series of options.
> > >
> > > If you access the SDSF through a batch process, the options that allow
> me
> > > to visualize the SDSF are different.
> > >
> > > In both situation the userid is the same
> > >
> > > Attached documentation of the problem.
> > >
> > > Thank you very much in advance.
> > >
> > > Hilario
> > >
> > > - Options from a TSO session
> > >
> > >  COMMAND INPUT ===>
> > >
> > >  DAActive users  INIT  Initiators
> > >  I Input queue   PRPrinters
> > >  O Output queue  PUN   Punches
> > >  H Held output queue RDR   Readers
> > >  STStatus of jobsLINE  Lines
> > >  NODE  Nodes
> > >  LOG   System logSOSpool offload
> > >  MAS   Members in the MAS
> > >  JCJob classes   ULOG  User session log
> > >  SEScheduling environments
> > >  RES   WLM resources
> > >
> > >  END   Exit SDSF
> > >
> > > - Options from a batch session
> > > COMMAND INPUT ===>
> > >
> > > DAActive users
> > > I Input queue
> > > O Output queue
> > > H Held output queue
> > > STStatus of jobs
> > >
> > > SEScheduling environments
> > >
> > > END   Exit SDSF
> > >
> > > - JCL used on batch
> > >
> > > //SDSFSTEP EXEC PGM=SDSF,PARM='++60,228'
> > > //ISFOUT DD SYSOUT=*
> > > //SYSPRINT DD SYSOUT=*
> > > //SYSOUTDD SYSOUT=*
> > > //ISFIN   DD *
> > > PRINT ODSN '.LST(JOBLOG)'
> > > PREFIX *
> > > OWNER *
> > > ST SDSFBAT
> > > ++ALL
> > > FIND SDSFBAT
> > > ++//X
> > > FIND SDSFBAT  LAST
> > > ++//
> > > PRINT
> > > PRINT CLOSE
> > > END
> > >
> > > Hilario
> > >
> > > --
> > > 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: SDSF on batch problem

[Hilario Garcia]

Hello,

Checking was performed using the OMS command of the SDSF and I assigned a
different GRPNAME for a different TSO session to a SDSF session in batch.
Under TSO, I am assigned the profile of ISFPRM00 as a system programmer and
under SDSF in batch that of a normal user.

Can someone tell me how I can modify the GRPNAME assignment for batch
processes executed by a systems programmer?

Thank you very much in advance. Hilario

El mié., 3 oct. 2018 a las 12:22, ITschak Mugzach ()
escribió:

> Try print the who command on both environments and compare the sdsf group
> first.
>
> ITschak
>
> בתאריך יום ד׳, 3 באוק׳ 2018, 8:56, מאת Hilario Garcia ‏ >:
>
> > Hello,
> >
> > I have an LPAR that when we access through a session of "TSO" to the SDSF
> > allows me a series of options.
> >
> > If you access the SDSF through a batch process, the options that allow me
> > to visualize the SDSF are different.
> >
> > In both situation the userid is the same
> >
> > Attached documentation of the problem.
> >
> > Thank you very much in advance.
> >
> > Hilario
> >
> > - Options from a TSO session
> >
> >  COMMAND INPUT ===>
> >
> >  DAActive users  INIT  Initiators
> >  I Input queue   PRPrinters
> >  O Output queue  PUN   Punches
> >  H Held output queue RDR   Readers
> >  STStatus of jobsLINE  Lines
> >  NODE  Nodes
> >  LOG   System logSOSpool offload
> >  MAS   Members in the MAS
> >  JCJob classes   ULOG  User session log
> >  SEScheduling environments
> >  RES   WLM resources
> >
> >  END   Exit SDSF
> >
> > - Options from a batch session
> > COMMAND INPUT ===>
> >
> > DAActive users
> > I Input queue
> > O Output queue
> > H Held output queue
> > STStatus of jobs
> >
> > SEScheduling environments
> >
> > END   Exit SDSF
> >
> > - JCL used on batch
> >
> > //SDSFSTEP EXEC PGM=SDSF,PARM='++60,228'
> > //ISFOUT DD SYSOUT=*
> > //SYSPRINT DD SYSOUT=*
> > //SYSOUTDD SYSOUT=*
> > //ISFIN   DD *
> > PRINT ODSN '.LST(JOBLOG)'
> > PREFIX *
> > OWNER *
> > ST SDSFBAT
> > ++ALL
> > FIND SDSFBAT
> > ++//X
> > FIND SDSFBAT  LAST
> > ++//
> > PRINT
> > PRINT CLOSE
> > END
> >
> > Hilario
> >
> > --
> > 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: S106 abends after copying into LINKLIST

[Elardus Engelbrecht]

Jesse 1 Robinson wrote:

>Whether 'tis nobler in the mind to suffer
>The slings and arrows of secondary extents, 
>Or to take arms against a sea of B37s,   
>And by opposing end them?   

Good one. +1 for you. For me: c all 'B37' 'ICH408I'  ;-)


>Gil may have been right about this being the October popic. For ServerPac data 
>sets, I encourage the *judicious* use of secondary extents. That's largely 
>because we (OK, almost) never update live data sets. We install maintenance in 
>a service-only container--oh snaps, I just made that up--and migrate it to a 
>live environment with an IPL. A swollen data set can be inconspicuously 
>compressed before it's (re)introduced to the wild. OTOH dealing with a data 
>set that has incrementally outgrown its original primary-only allocation can 
>be a major PITA even in a service-only container. 

Agreed. This is why there is the ability to do 'rolling maintenance'. You leave 
out live things out and setup new IPL/other volsers with bigger than big 
datasets.

Of course, can you do that or not. YMMV.


>The catch is that You Need to Know What You're Doing. I know, this requirement 
>offends manage-by-airline-rag execs who see knowledge and experience as 
>obstacles to hiring practices. So be it.

Those 'manage-by-airline-rag' execs also are extrememely offended (because of 
no brain cells) by this:

1. No applying fixes on 'live' things.
2. Downtime and approvals and double check-outs/verifications are needed.
3. z/OS does not need 'three finger salute' (CTRL-ALT-DEL for reboot).
4. Nothing to click on. no GUI. (yes, I know about the new products with GUI 
interfaces, but ... )
5. ... etc ...


>...  after a couple of years' worth of new function before the next ServerPac, 
>anticipating the long-term growth of every library is pretty much a crapshoot. 

This is why you see in Program Directories the required space for each 
dataset/OMVS files needed for each product you ordered.


>Defining secondary extents that may or may not be needed in the current 
>release is a fairly cheap maneuver to head off an inconvenient space crunch.  

We discourage updates of live modules, but 'they' won't listen. Only when 
something crash, then 'they' rememeber... :-(


>As we all agree, install fixes on live systems infrequently and with great 
>care, but IBM has invested tons in mechanisms that make continuous 
>availability possible if not trivial. Just come clean that it's this or 
>guaranteed IPL. I've made a handful of gambles over the years. Won more than 
>I've lost, but each one is a cliff hanger.

You're a true risk taker! ;-D


Seymour J Metz wrote:

>I stated that I *prefer* to never update I live linklist library, not that I 
>wouldn't or haven't done it in an emergency situation. What I do to avoid an 
>outage is not what is sound for routine maintenance.

Good. Unless you are in a catch-22 situation, but I believe you also *prefer* 
not to be there. ;-)

This thread is a very interesting one. Thanks!

Groete / Greetings
Elardus Engelbrecht

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