Enterprise COBOL "INITCHECK"

[Frank Swarbrick]

This could be quite a useful new feature:


"The compiler is changed to add a new compiler option: INITCHECK, which tells 
the compiler to try and locate uses of data items that have not been set yet. 
The compiler is changed to add a new compiler option: INITCHECK".


V6.1: http://www-01.ibm.com/support/docview.wss?uid=swg1PI68226

V5.2: http://www-01.ibm.com/support/docview.wss?uid=swg1PI69197

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

Re: VSAM CA reclaim for RMM

[Jesse 1 Robinson]

I’m not a STORAGE guy. It means that I can look at stuff created by someone 
else. We seem to make odd use of DATACLAS here, but LISTCAT on the RMM data 
base shows that it's eligible. I also looked a troublesome user catalog; it's 
eligible as well. 

Meanwhile I turned on CA reclaim in the sandbox environment just make sure we 
don't experience problems. Wait and see.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Shirey
Sent: Friday, October 07, 2016 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: VSAM CA reclaim for RMM

Skip, 

The IGDSMSxx setting is either NONE or DATACLAS.  So, it's not quite global - 
the VSAM file must be assigned a DATACLAS at creation which has CA RECLAIM set 
to Y.   

We modified all our Data Classes sometime in mid-2012, so our SMS-managed VSAM 
files have been reclaiming CA's for years.   I spent a lot of time trying to 
determine a method of proving any benefit or detriment but never could.  

Sorry to be late joining the thread, been out for a few days... 

Regards,
Greg Shirey
Ben E. Keith Company


-Original Message-
From: Jesse 1 Robinson [mailto:jesse1.robin...@sce.com] 
Sent: Thursday, September 29, 2016 4:03 PM
Subject: Re: VSAM CA reclaim for RMM

Correcting ALTER syntax.

-Original Message-
From: Jesse 1 Robinson 
Sent: Thursday, September 29, 2016 1:59 PM
To: 'IBM Mainframe Discussion List' 
Subject: Re: VSAM CA reclaim for RMM

Thanks. Spent some time this morning wading through the doc. Here's a thumbnail 
version of my understanding.

-- CA reclaim must be 'turned on' at the system level in PARMLIB IGDSMSxx. 
Default value is 'off'.
-- It can also be turned on or off for a system with a SETSMS command.
-- Once turned on globally, CA reclaim will be in effect for (more or less) 
every VSAM cluster unless a cluster is specifically turned off. That is, the 
default at the cluster level is on. My RMM control data set is 'on' as shown by 
LISTCAT.  
-- You can turn a cluster off or back on with a simple ALTER command--which BTW 
I cannot find documented anywhere except in KC discussions of CA reclaim. For 
example, I cannot find any reference to reclaim in TSO HELP for ALTER.
-- The IDCAMS command is "ALTER entry-name RECLAIMCA/NORECLAIMCA". That command 
is accepted now when I enter it even though we do not have reclaim turned on 
globally. 

So if you turned reclaim on for 'some user catalogs' and for SMS control data 
sets, did you take any action to turn it off for everything else in the house?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


> When CA reclaim was first presented at a closed SHARE session on a Sunday 
> morning, there was great interest in the room but also some skepticism.  What 
> is the current consensus on CA reclaim? How extensively is it implemented 
> these days? Recommendations?
>


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

Checklists Bring Order Out of Chaos and Enhance Reliability

[Gabe Goldberg]

Checklists Bring Order Out of Chaos and Enhance Reliability
Systematic procedures help avoid and solve problems

After spending a career with mainframes, I prefer order to chaos. I like 
the deterministic manner in which mainframe OSes are maintained (audit 
trails, full piece-part identification, systematic system builds, 
standardized maintenance tools, maintenance history, etc.) more than the 
free-fire frontier mentality for configuring, maintaining and debugging 
Windows PCs (plug-and-pray, installs which sprinkle random files 
everywhere, rebooting to ignore vanquish problems, etc.). Even logging 
changes to my PC, I feel at the mercy of the next software install which 
mysteriously corrupts a working system. But I take some comfort from 
detailed records and notes on how I've done things and set up systems so 
I can retrace my path.


In the same manner, when my wife prepares her favorite contribution to 
potluck events, rum cake, she follows a written recipe (see below). I've 
teased her about needing—or at least wanting—instructions, but I admire 
her process and see that it mirrors mine. I'm happy that the only 
variable between cakes is whether they include chocolate chips and nuts, 
with no risk of key ingredients forgotten.


http://destinationz.org/Mainframe-Solution/Trends/Checklists-Bring-Order-Out-of-Chaos-and-Enhance-Re
http://tinyurl.com/z7jlecx

...plus, Kim's rum cake recipe!

--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0

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

Re: VSAM CA reclaim for RMM

[Greg Shirey]

Skip, 

The IGDSMSxx setting is either NONE or DATACLAS.  So, it's not quite global - 
the VSAM file must be assigned a DATACLAS at creation which has CA RECLAIM set 
to Y.   

We modified all our Data Classes sometime in mid-2012, so our SMS-managed VSAM 
files have been reclaiming CA's for years.   I spent a lot of time trying to 
determine a method of proving any benefit or detriment but never could.  

Sorry to be late joining the thread, been out for a few days... 

Regards,
Greg Shirey
Ben E. Keith Company


-Original Message-
From: Jesse 1 Robinson [mailto:jesse1.robin...@sce.com] 
Sent: Thursday, September 29, 2016 4:03 PM
Subject: Re: VSAM CA reclaim for RMM

Correcting ALTER syntax.

-Original Message-
From: Jesse 1 Robinson 
Sent: Thursday, September 29, 2016 1:59 PM
To: 'IBM Mainframe Discussion List' 
Subject: Re: VSAM CA reclaim for RMM

Thanks. Spent some time this morning wading through the doc. Here's a thumbnail 
version of my understanding.

-- CA reclaim must be 'turned on' at the system level in PARMLIB IGDSMSxx. 
Default value is 'off'.
-- It can also be turned on or off for a system with a SETSMS command.
-- Once turned on globally, CA reclaim will be in effect for (more or less) 
every VSAM cluster unless a cluster is specifically turned off. That is, the 
default at the cluster level is on. My RMM control data set is 'on' as shown by 
LISTCAT.  
-- You can turn a cluster off or back on with a simple ALTER command--which BTW 
I cannot find documented anywhere except in KC discussions of CA reclaim. For 
example, I cannot find any reference to reclaim in TSO HELP for ALTER.
-- The IDCAMS command is "ALTER entry-name RECLAIMCA/NORECLAIMCA". That command 
is accepted now when I enter it even though we do not have reclaim turned on 
globally. 

So if you turned reclaim on for 'some user catalogs' and for SMS control data 
sets, did you take any action to turn it off for everything else in the house?

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


> When CA reclaim was first presented at a closed SHARE session on a Sunday 
> morning, there was great interest in the room but also some skepticism.  What 
> is the current consensus on CA reclaim? How extensively is it implemented 
> these days? Recommendations?
>


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

Re: CEEDUMP possible following 'new' failure

[Greg Dyck]

On 10/7/2016 1:38 PM, Jim Mulder wrote:

  Since memterm does not access the storage of the address
being terminated, there is no connection between IEFUSI and memterm.
There is no requirement for any available storage in the address
space being memtermed.  Task termination, yes.
Memory termination, no.


I think have been cases where an address space determined it was in 
trouble and wanted to MEMTERM itself, but unable to issue a CALLRTM 
MEMTERM for *itself* due to storage being exhausted.  But, as Jim said, 
a FORCE command runs in *MASTER* and does not need any storage in the 
address space.


Greg

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

Re: CEEDUMP possible following 'new' failure

[Jim Mulder]

> this reminds me of some hanging IMS jobs that could neither be 
> cancelled nor forced because the routines for memterm could not be 
> loaded because of memory exhausted. Only BMC Tooling allowed to get 
> rid of them.
> The suggestion in the PMR was to code an IEFUSI to reserve 512k 
> below to allow memterm to happen in any case.
> 
> Could you please raise another internal discussion why IEFUSI has to
> be coded at all in order to allow memterm to happen?
> Why can't z/OS just ensure that there is always enough storage 
> available in the address space for memterm?

  Since memterm does not access the storage of the address 
being terminated, there is no connection between IEFUSI and memterm.
There is no requirement for any available storage in the address
space being memtermed.  Task termination, yes. 
Memory termination, no. 


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




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

Re: Fwd: Shark Tank: Is this why mainframes almost never get rebooted?

[Tom Brennan]

I did about the same:  My first x86 box came with an apparent pirate 
copy of Win 3.1 (no install disks) and I accidentally deleted all the 
files in C:\WINDOWS.  With UNDELETE you have to know the first character 
of the original filename, so for the ones I couldn't guess I called up 
my brother and asked him to check his own 3.1 system.  Eventually I was 
back in business.


Mike Schwab wrote:

Yep.  Helped a co-worker who deleted all the files in the C:\
directory on Win 95 about 1997.  Undeleted most files and rebooted
with system disk and restored IO.SYS, etc with special command from
floppy.  Help desk was taking a long time to come over to fix it.



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

Re: Fwd: Shark Tank: Is this why mainframes almost never get rebooted?

[Mike Schwab]

Yep.  Helped a co-worker who deleted all the files in the C:\
directory on Win 95 about 1997.  Undeleted most files and rebooted
with system disk and restored IO.SYS, etc with special command from
floppy.  Help desk was taking a long time to come over to fix it.

On Fri, Oct 7, 2016 at 7:46 AM, Elardus Engelbrecht
 wrote:
> Mark Regan wrote:
>
>>http://www.computerworld.com/article/3126852/data-center/is-this-why-mainframes-almost-never-get-rebooted.html
>
> Funny and plausible war story! ;-)
>
> It reminds me of an a$$hole who edited his autoexec.bat to contains only one 
> line which has the program name which he wants to run after reboot.
>
> Unfortunately for him that file also PREVIOUSLY contained some setup 
> statements for memory management, path, environment variables and other 
> things...
>
> So, reboot failed of course. Of course, I had to fix it by using a floppy to 
> boot with.
>
> ;-)
>
> 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



-- 
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: Software is unpatentable?

[Joel C. Ewing]

On 10/07/2016 07:21 AM, John McKown wrote:
> https://news.slashdot.org/story/16/10/07/0455200/prominent-pro-patent-judge-issues-opinion-declaring-all-software-patents-bad
>
> http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/15-1769.Opinion.9-28-2016.1.PDF
>
Amazing!  The courts may finally be on the verge of returning patents to
what they were intended to protect:  the invention of physical objects
that require significant investment in physical infrastructure to
research, develop, and manufacture -- not concepts and algorithms that
can be discovered or  re-discovered by anyone with a writing instrument
and a recording media just by employing basic concepts of logic and
algorithmic design.  Congress had no idea what they were doing when they
opened the door to software and business method patents.
Joel C. Ewing

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: RFE 73512 - "Better use of ISPF screen names in SDSF"

[Dana Mitchell]

On Wed, 5 Oct 2016 22:18:20 +, Robert Prins  
wrote:
>
>To those unfamiliar with the concept of SHADOW variables, a copy of Doug 
>Nadel's
>Share Winter 1999 paper "ISPF Panels Beyond the Basics" can be found at this
>ridiculously long and wrapping URL
>
>
>It's well worth a read!
>
>Robert
>

Thanks, I'll read that when I get the chance,  I wasn't familiar with shadow 
variables before.

Also, as Alan Field pointed out, there was another conflict in Doug's code with 
current ISFPCU41.   IBM has defined x'82'  and x'87' TYPE(CHAR) attributes in 
the base panel,  and Doug has 'b' and 'g' coded for some of his.  I just 
changed his attributes to 'k' and 'j' respectively in the )ATTR section,  and 
also where he referenced them on 'Call add' statements in the customization 
section.

Dana

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

Re: Fwd: Shark Tank: Is this why mainframes almost never get rebooted?

[Elardus Engelbrecht]

Mark Regan wrote:

>http://www.computerworld.com/article/3126852/data-center/is-this-why-mainframes-almost-never-get-rebooted.html

Funny and plausible war story! ;-)

It reminds me of an a$$hole who edited his autoexec.bat to contains only one 
line which has the program name which he wants to run after reboot.

Unfortunately for him that file also PREVIOUSLY contained some setup statements 
for memory management, path, environment variables and other things...

So, reboot failed of course. Of course, I had to fix it by using a floppy to 
boot with.

;-)

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

Software is unpatentable?

[John McKown]

https://news.slashdot.org/story/16/10/07/0455200/prominent-pro-patent-judge-issues-opinion-declaring-all-software-patents-bad

http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/15-1769.Opinion.9-28-2016.1.PDF

-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

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

Fwd: Shark Tank: Is this why mainframes almost never get rebooted?

[Mark Regan]

http://www.computerworld.com/article/3126852/data-center/is-this-why-mainframes-almost-never-get-rebooted.html

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

Re: Apar PM67033: WTOR MESSAGE DFHPA1909 nothing seems to work

[Jantje.]

On Thu, 6 Oct 2016 13:41:15 -0700, John Mattson  
wrote:

>68 DFHPA1909 TECHCICS DATA INVALID FOR 'USSHOME'. RESPECIFY KEYWORD AND
>DATA OR *BYPASS WITH '.END': '/usr/lpp/cicsts/cicsts52 *

According to the doc 
https://www.ibm.com/support/knowledgecenter/SSGMCP_5.2.0/com.ibm.cics.ts.messages.doc/DFHPA/DFHPA1909.html
 you can reply with a blank line to skip. Did you try that?
Cheers,

Jantje.

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

Re: CEEDUMP possible following 'new' failure

[Denis]

Hi,
 
this reminds me of some hanging IMS jobs that could neither be cancelled nor 
forced because the routines for memterm could not be loaded because of memory 
exhausted. Only BMC Tooling allowed to get rid of them.
The suggestion in the PMR was to code an IEFUSI to reserve 512k below to allow 
memterm to happen in any case.
 
Could you please raise another internal discussion why IEFUSI has to be coded 
at all in order to allow memterm to happen?
Why can't z/OS just ensure that there is always enough storage available in the 
address space for memterm?
 
Thanks.
 
 
-Original Message-
From: Jim Mulder 
To: IBM-MAIN 
Sent: Thu, Oct 6, 2016 10:33 pm
Subject: Re: CEEDUMP possible following 'new' failure

>From some internal discussion after this issue was raised today,
our intention is that LE will move the CEEDUMP modules to SCEELPA 
in the next release of z/OS. 

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

> 
> So, when  will CEE.SCEELPA be z/OS standard? :) 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Jim Mulder
> > Sent: Thursday, October 06, 2016 10:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: CEEDUMP possible following 'new' failure
> > 
> > > The remaining problem is that I am not getting any diagnostic
> > information,
> > > in other words, exactly *which* new failed -- which will of course
> > > make
> > any
> > > bug of this sort in the field hard to find. I call CEEDUMP to get a
> > > call trace and it produces an *empty* four-line dataset. On the
> > > console I get
> > >
> > > IEW4000I FETCH FOR MODULE CEEMENU3 FROM DDNAME *VLF* FAILED
> > BECAUSE
> > > INSUFFICIENT STORAGE WAS AVAILABLE.
> > > CSV031I LIBRARY ACCESS FAILED FOR MODULE CEEMENU3, RETURN CODE
> > 24,
> > REASON
> > > CODE 26080021, DDNAME *LNKLST*
> > 
> >   I would suggest putting the CEEDUMP-related modules in LPA.  Our
> > intention in z/OS is that modules involved in the production of
> > SYSABEND/SYSUDUMP/SYSMDUMP/IEATDUMP/SDUMP
> > should be in LPA, so that they don't need get loaded into exhausted 
REGION-
> > constrained storage while trying to take a dump of REGION-constrained
> > storage exhaustion.  (And I say "our intention"
> > because we do sometimes find cases where we did not do what we
> > intended).



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

AW: Re: CEEDUMP possible following 'new' failure

[Peter Hunkeler]

>From some internal discussion after this issue was raised today,
our intention is that LE will move the CEEDUMP modules to SCEELPA
in the next release of z/OS.




Didn't look up and didn't care so far, but now that you mention it, I'm 
astonished those modules are not currrently part of LE's LPA library. Could you 
please have another internal discussion :-) and provide list of the   the LE 
recovery and dump modules which are not currently in LPA but should be?


--
Peter Hunkeler



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