Re: CSVFETCH exit

[Peter Relson]

Just FYI, there's a pretty blatant doc error of my causing in the z/OS 2.2 
data. A doc APAR has been, or soon will be, provided.

The doc says that the exit routine gets control with reg 1 pointing to a a 
2 word area, the first word being the address of a work area that the exit 
routine can use, the second being the address of the parameter area.

In reality it is the reverse. The first address is the address of the 
parameter area, the second the address of the work area.

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

Re: CSVFETCH exit

[Leonardo Vaz]

I noticed that, was going to open a PMR on Monday, thanks for reporting here.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Saturday, February 13, 2016 11:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CSVFETCH exit

Just FYI, there's a pretty blatant doc error of my causing in the z/OS 2.2 
data. A doc APAR has been, or soon will be, provided.

The doc says that the exit routine gets control with reg 1 pointing to a a
2 word area, the first word being the address of a work area that the exit 
routine can use, the second being the address of the parameter area.

In reality it is the reverse. The first address is the address of the parameter 
area, the second the address of the work area.

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

Re: Real Storage Allocation

[Martin Packer]

As for monitoring use SMF 71 (RMF Paging Activity) data, most especially 
MINIMUM as well as AVERAGE Available Frame Count. Study how they both 
behave with time and how the Minimum deviates from the Average.

That's what Dave Betten and I do in every engagement. And Dave probably 
has some choice words on how to manage DFSORT use of memory - which often 
accounts for the difference.

One thing I would say is: Understand how your choices help or hinder your 
ability to add memory to LPARs - whether the one it's allocated to or a 
different one that subsequently needs it. This, to me, is still not an 
exact science. I would argue the instrumentation (again SMF 71) could be 
better in this area.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   "Rugen, Len" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/02/2016 22:40
Subject:Re: Real Storage Allocation
Sent by:IBM Mainframe Discussion List 



I'd say it depends on your workload :-) 

If you are doing I/O that could be avoided with more buffers, it would be 
used.  Sort might be able to use it, if you sort much. 

I once did amazing things increasing CICS temp storage buffers :-)

Len Rugen

University of Missouri
Division of Information Technology
Systems & Operations - Metrics & Automation Team


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf 
of phil yogendran [philyo...@gmail.com]
Sent: Friday, February 12, 2016 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Real Storage Allocation

Hello,

Is there a downside to over-allocating real storage on an LPAR?

We will be upgrading current processors which are tired and soon to be out
of service to z13's which will have 4 times the storage we have at 
present.

We don't have any issues with paging or UIC etc. but I feel that on the 
new
processors, I need to make use of most if not all that available storage.

Some of my thoughts are;

- Will the additional storage be used on an LPAR which already has enough
to do it's work.
- Is there a way to monitor for 'unused' storage?
- If the storage is not used, is there a loss of cycles in an 'overhead' 
to
managing this unused storage?
- etc.

Your comments will be appreciated.

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: [Bulk] Re: Even after all the Y2K work....

[Skip Robinson]

Does anyone else have a certain cockeyed nostalgia for Doomsdays that just 
never materialize? They are so entertaining. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mike Schwab
> Sent: Wednesday, February 10, 2016 08:18 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Even after all the Y2K work
> 
> Not too young to remember 2012.
> Who remembers the year without a December?
> http://www.androidcentral.com/santa-s-going-be-mad-google-forgot-about-
> december
> I guess that was one way to avoid the Doomsday of December 21, 2012.
> 
> On Wed, Feb 10, 2016 at 10:04 AM, Field, Alan
>  wrote:
> > Probably too young to remember Y2K.
> >
> > Alan Field
> > Systems Engineer Principal
> > Blue Cross Blue Shield of MN
> >
> > 651.662.3546
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Tony Thigpen
> > Sent: Wednesday, February 10, 2016 9:54 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: OT: Even after all the Y2K work
> >
> > You would think coders would understand leap days.
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.calculatorcat.
> > com_free-5Fcalculators_day-5Fof-
> 5Fweek.phtml=BQICaQ=zjLIypOkeQKJfe
> > 4BYrJ5J55pYA-45JElRiaMoh2hP7Q=SaL11MvL9LWz-
> 4CkTmMYltgrRR9mrR4t5HY7AK
> >
> mOSPE=dzfOZigM6RzsZpwmqZ9ikEQkWF4XyxYWJl15RO0CRa8=Rgk_6sV
> 6OuCAEexz
> > ynTDXMLw0iK0tpzFcIGOmTkb84w= Enter Feb 29, 2016 (or any other valid
> > leap year) and you get:
> >
> > "The date February 29, 2016 is invalid.
> > Check it again."
> >
> >
> > --
> > Tony Thigpen

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

Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Ed Gould]

Skip:

I concur. A second cousin war story was that there was a RACF  
"screwup" (ie operator error) took a data center down for a long time  
(more than a few hours). The DC was designed for the one of the  
Chicago markets. The lead sysprog at the time (I thing he is no  
longer with us) was there at the time.
We had a separate DC on the same floor and I think the blood letting  
was felt by everyone.
If memory serves me we had just converted to MVS and went ACF2. I  
don't think the question ever arose in our DC about what IF, but we  
sure should have.

Ed
On Feb 13, 2016, at 10:04 PM, Skip Robinson wrote:

This opinion is based on (thankfully) limited experience. If you  
are forced
to IPL without a usable RACF data base, you are totally scr*wed.  
During IPL,
operator will be prompted to allow even READ access to *every* data  
set

opened by *every* task except for a tiny handful like JES that bypass
integrity. By the time you get to the point of actually logging on  
to TSO,
operator's fingers will be bleeding profusely. If at any time  
during this
process, you are god-forbid required to start over, yet more finger  
tips

will have to sacrificed.

Whatever UADS is worth, IPLing without a RACF data base is the last  
extreme

recovery option. Please plan a next-to-last option.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of John Eells
Sent: Monday, February 1, 2016 08:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

I hadn't really thought about (or researched) the display  
capabilities of

RACF.

An RFE couldn't hurt if you find them lacking.

Once one's TSO/E administrative routines have been converted to  
use the

TSO

segment, though, I think another good use of UADS is for recovery,

including
DR. It's the only way to log on when you have no security  
database, at

least
when RACF is the absent DB in question. I'd want to have "some  
number" of
sysprog user IDs to be in UADS for recovery purposes. (And an  
appropriate

MPF exit, for RACF!)

As SA restore is a serial activity and batch restore is not,  
minimizing

recovery
time would seem to call for a small number of UADS-defined IDs to  
speed
overall restore time if your security DB happens not to share a  
volume

with

some other data sets required to IPL and log on. But what do I know?

Skip Robinson wrote:
Ah, UADS. A prime example of archaic mechanism. Defensible  
technically?

Probably not, although a security administrator who needs to know
which account numbers or which proclibs a user is authorized to use
might tell a different story. With UADS, a simple list command tells
the story. With TSOE segment, it's a data mining operation. This
difference alone has inhibited conversion in some shops.



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


--
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: Old code in JES Exit 6

[Skip Robinson]

Just an observation that historically JES2 (and maybe JES3) have meticulously 
accompanied control block changes with macro label changes. For example, if a 
field changes from halfword to fullword, then the name is changed as well. The 
resulting user mod/exit assembly error is a huge red flag that customer code 
has to change. Somehow. Nothing is/would be worse than trying to debug errors 
resulting from unmarked control block changes. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Friday, February 12, 2016 08:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] Re: Old code in JES Exit 6
> 
> On 2/12/2016 5:55 AM, Staller, Allan wrote:
> > You have some code to write.
> > Look at "z/OS MVS Using the Functional Subsystem Interface"
> > SA38-0678-00 (for z/OS 2.1)
> >
> > More and more of the stuff that used to be in JES CB's is being moved to the
> FSS(SAPI)  and can only be obtained via this method.
> >
> > It is not too difficult to write, but the trick will be integrating it with 
> > your
> existing exit code.
> 
> The SSI cannot be used to access the needed work areas from within exit 6.
> 
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/

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

Re: Problem subscribing to IBM-MAIN

[Ed Finnell]

Can you get to the web interface? listserv.ua.edu/archives/ibm-main.html  
will let you perform subscription services.
 
 
In a message dated 2/13/2016 11:01:29 P.M. Central Standard Time,  
jo.skip.robin...@att.net writes:

I  addressed this note to Darren but have not received a reply. Trying to
move  my subscription to my new 'office' account. Not working for  reasons
indicated. 


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

Re: [Bulk] Re: Even after all the Y2K work....

[Linda]

Hi Skip,

Yep. They are the best kind. ;)

Linda

Sent from my iPhone

> On Feb 13, 2016, at 8:31 PM, Skip Robinson  wrote:
> 
> Does anyone else have a certain cockeyed nostalgia for Doomsdays that just 
> never materialize? They are so entertaining. 
> 
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> jo.skip.robin...@att.net
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Mike Schwab
>> Sent: Wednesday, February 10, 2016 08:18 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [Bulk] Re: Even after all the Y2K work
>> 
>> Not too young to remember 2012.
>> Who remembers the year without a December?
>> http://www.androidcentral.com/santa-s-going-be-mad-google-forgot-about-
>> december
>> I guess that was one way to avoid the Doomsday of December 21, 2012.
>> 
>> On Wed, Feb 10, 2016 at 10:04 AM, Field, Alan
>>  wrote:
>>> Probably too young to remember Y2K.
>>> 
>>> Alan Field
>>> Systems Engineer Principal
>>> Blue Cross Blue Shield of MN
>>> 
>>> 651.662.3546
>>> 
>>> -Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>>> On Behalf Of Tony Thigpen
>>> Sent: Wednesday, February 10, 2016 9:54 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: OT: Even after all the Y2K work
>>> 
>>> You would think coders would understand leap days.
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.calculatorcat.
>>> com_free-5Fcalculators_day-5Fof-
>> 5Fweek.phtml=BQICaQ=zjLIypOkeQKJfe
>>> 4BYrJ5J55pYA-45JElRiaMoh2hP7Q=SaL11MvL9LWz-
>> 4CkTmMYltgrRR9mrR4t5HY7AK
>> mOSPE=dzfOZigM6RzsZpwmqZ9ikEQkWF4XyxYWJl15RO0CRa8=Rgk_6sV
>> 6OuCAEexz
>>> ynTDXMLw0iK0tpzFcIGOmTkb84w= Enter Feb 29, 2016 (or any other valid
>>> leap year) and you get:
>>> 
>>> "The date February 29, 2016 is invalid.
>>> Check it again."
>>> 
>>> 
>>> --
>>> Tony Thigpen
> 
> --
> 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

PIPFRE122E Insufficient free storage.

[Paul Gilmartin]

(This is a pipelines problem, rather than a VM problem.  But I may
get better diagnostic information here.)

I'm getting:

   411 *-*  drop Holds.
   412 *-*  'callpipe command LISTFILE' ptf_name 'HOLD*' Opt.9MVSFM '(ISO 
NOH)' ,   '| sort word
 8.9 desc' ,   '| spec
 word 1.3' ,   '| stem Holds.'
   >>>"callpipe command LISTFILE L1H18J0 HOLD* B (ISO NOH) | sort 
word 8.9 desc | spec word
1.3 | stem Holds."
PIPFRE122E Insufficient free storage.
PIPMSG002I ... Processing "callpipe command LISTFILE L1H18J0 HOLD* B (ISO NOH".
   +++ RC(-122) +++

What command can I use periodically, in my loop, to isolate the memory leak.
I knew how to do this, decades ago, but I've forgotten much, and it may have
been before VM/XA.

I think it's slow leak; not catastrophic.  In this case, LISTFILE would
just get RC=28.

Thanks,
gil

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

Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

[Skip Robinson]

This opinion is based on (thankfully) limited experience. If you are forced
to IPL without a usable RACF data base, you are totally scr*wed. During IPL,
operator will be prompted to allow even READ access to *every* data set
opened by *every* task except for a tiny handful like JES that bypass
integrity. By the time you get to the point of actually logging on to TSO,
operator's fingers will be bleeding profusely. If at any time during this
process, you are god-forbid required to start over, yet more finger tips
will have to sacrificed. 

Whatever UADS is worth, IPLing without a RACF data base is the last extreme
recovery option. Please plan a next-to-last option.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
jo.skip.robin...@att.net

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of John Eells
> Sent: Monday, February 1, 2016 08:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)
> 
> I hadn't really thought about (or researched) the display capabilities of
RACF.
> An RFE couldn't hurt if you find them lacking.
> 
> Once one's TSO/E administrative routines have been converted to use the
TSO
> segment, though, I think another good use of UADS is for recovery,
including
> DR. It's the only way to log on when you have no security database, at
least
> when RACF is the absent DB in question. I'd want to have "some number" of
> sysprog user IDs to be in UADS for recovery purposes. (And an appropriate
> MPF exit, for RACF!)
> 
> As SA restore is a serial activity and batch restore is not, minimizing
recovery
> time would seem to call for a small number of UADS-defined IDs to speed
> overall restore time if your security DB happens not to share a volume
with
> some other data sets required to IPL and log on. But what do I know?
> 
> Skip Robinson wrote:
> > Ah, UADS. A prime example of archaic mechanism. Defensible technically?
> > Probably not, although a security administrator who needs to know
> > which account numbers or which proclibs a user is authorized to use
> > might tell a different story. With UADS, a simple list command tells
> > the story. With TSOE segment, it's a data mining operation. This
> > difference alone has inhibited conversion in some shops.
> 
> 
> --
> 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

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

Problem subscribing to IBM-MAIN

[Skip Robinson]

I addressed this note to Darren but have not received a reply. Trying to
move my subscription to my new 'office' account. Not working for reasons
indicated. 

.

.

.

J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
  jo.skip.robin...@att.net

 

From: Skip Robinson [mailto:jo.skip.robin...@att.net] 
Sent: Wednesday, February 10, 2016 09:11 AM
To: 'dar...@bama.ua.edu' 
Cc: Dinesh Subramanian/SCE 
Subject: Problem subscribing to IBM-MAIN

 

Darren,

 

I'm trying to move my IBM-MAIN subscription to my new (and execrable) email
address at sce.com. The process is failing most likely for the same reason
we had trouble with new subscriptions last year: the initial email from
LISTSRV contains no 'Sender' in the header, causing our email system to
reject it as spam. Actual posts are OK; it's the pro forma note that goes
awry. Could I ask you to handle this one manually? Thanks. 

 

Skip Robinson

jesse1.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: Problem subscribing to IBM-MAIN

[Ed Gould]

On Feb 13, 2016, at 11:01 PM, Skip Robinson wrote:

I addressed this note to Darren but have not received a reply.  
Trying to
move my subscription to my new 'office' account. Not working for  
reasons

indicated.

.

.


Good luck Skip. I sent a note to Darren 6 or so months ago I never  
got an answer. About a month later I got a reply but he didn't seem  
all that interested.

I am beginning to think Darren is like TSO, moribund.

Ed

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