date:20130912

You might try this url

https://www-304.ibm.com/support/docview.wss?uid=isg3S1000411

Problems with ACS routines and how to set an ACS trace

I am not sure how to pull the ACS Trace and read it after it is collected.

I like a tool called SMSDEBUG for this, but that is a purchase.

Lizette

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Vernooij, CP - SPLXM
Sent: Thursday, September 12, 2013 1:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ACS routine trace.

Hello,

 

I have an problem in my StorClas ACS routine, which I cannot put my finger
on. 

The routine is suspected to not assign a Storclas to an allocation request,
which causes the request to fail. However I cannot find if it really does
and if so, why. WRITE commands are useless, because these messages will
never be displayed if the allocation is done by dynamic allocation, which is
the case here.

 

Is there any other way to find out what my StorClas routine does and
decides?

 

Thanks,

Kees.

 


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

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


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

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

Re: SSI update

If you look at your Logrec SOFTWARE records, it should help to shed some
light on your issue.

Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of mf db
Sent: Wednesday, September 11, 2013 9:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SSI update

Hello Sir,

Apology for the confusion, Recently in one of my test system I added a
subsystem to SSI and i have started experiencing recursive abends. After
adding I started seeing some of the STC which were started taking more Real
storage(Which Usually doesn't take much during normal).


On Wed, Sep 11, 2013 at 8:34 PM, Jon Perryman jperr...@pacbell.net wrote:

 I'm also confused by your question. What makes you ask this question? 
 What did you read or hear about that made you ask this question? Are 
 you talking about the subsystem interface or is SSI in reference to
something else?

 Any time a program moves information to storage, it is overlaying storage.
 It's only a bad thing when it overlays the wrong storage. We use the 
 term storage overlay to mean overlaying the wrong storage. Assembler 
 macro IEFSSI and MVS command SETSSI add/update the SSCT which overlays 
 information in an SSCT or the SSCT chain. If your program overlays the 
 wrong storage, then it can cause abends.

 Great care must be taken in programs that run from the SSI. The SSI 
 runs all the time and in all address spaces. If something bad happens, 
 you could be IPL'ing your system.

 Jon Perryman..




 
  From: mf db dbajava...@gmail.com

 Yes, My question can it cause any abend by overlaying storage ?
 
 On Wed, Sep 11, 2013 at 2:43 PM, Lizette Koehler 
 stars...@mindspring.com
 wrote:
  Are you asking can it cause an abend by overlaying storage?
 
  -Original Message-
 From: mf db dbajava...@gmail.com
 
  I am trying to understand if Dynamic SSI update can overlay the
storage.
  Could someone please shed some light on dynamic SSI update.


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

Re: ACS routine trace.

At z/OS V1.7 and above (I think) you use IPCS to unload the trace data.

VERBX SMSDATA 'TRACE'

Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Thursday, September 12, 2013 1:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ACS routine trace.

You might try this url

https://www-304.ibm.com/support/docview.wss?uid=isg3S1000411

Problems with ACS routines and how to set an ACS trace

I am not sure how to pull the ACS Trace and read it after it is collected.

I like a tool called SMSDEBUG for this, but that is a purchase.

Lizette

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Vernooij, CP - SPLXM
Sent: Thursday, September 12, 2013 1:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ACS routine trace.

Hello,

 

I have an problem in my StorClas ACS routine, which I cannot put my finger
on. 

The routine is suspected to not assign a Storclas to an allocation request,
which causes the request to fail. However I cannot find if it really does
and if so, why. WRITE commands are useless, because these messages will
never be displayed if the allocation is done by dynamic allocation, which is
the case here.

 

Is there any other way to find out what my StorClas routine does and
decides?

 

Thanks,

Kees.

 

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

Re: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Timothy Sipples

I'm not disagreeing with my colleague Jim Mulder -- or with John Gilmore
for that matter. When I wrote PDSEs and their impacts I was referring to
any/all impacts to meet the PDSE prerequisite for Enterprise COBOL 5.1 (as
described in the Enterprise COBOL 5.1 documentation), including the ones
enumerated in this thread. That's precisely why I recommend taking up IBM
on the trial offer, to figure out the impacts in your environment. Most of
them will probably be very welcome impacts, but maybe not all.

At the same time I think it's important to applaud the fact that IBM is
moving COBOL forward, and the feedback I've been getting (and reading)
about the new compiler is generally very positive. This is an excellent new
compiler. I also love the fact that there's now a clear path to 64-bit
COBOL with some welcome constraint relief in the meantime.

The answer can't be move forward IBM, but there can be no operational
impacts whatsoever, ever. That's the wrong answer -- and most probably
impossible anyway. I'm guessing that's the point John Gilmore was making.
There has to be a balance. The balance is generally going to be fairly
conservatively skewed in this mission-critical world we inhabit. But
occasionally there will be some impacts (of varying but hopefully modest
size) as progress is made. Let's figure out the best ways to work through
them and to mitigate them, but let's keep forging ahead, too.

By the way, while I don't think a 2013 PDSE prerequisite is too soon, here
are some marketing efforts that are too soon (at least):

http://www.slate.com/blogs/moneybox/2013/09/11/at_t_9_11.html
http://www.huffingtonpost.com/2013/09/11/marriott-september-11-9_n_3907684.html


Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Wait all CPU's enabled at least once

Jon Perryman wrote:

Is there an instruction that waits for all CPU's to be enabled at least once?

I saw Jim's reply and reread my PrOPs, but why do you want all CPU's to be 
enabled? What type of CPU? 

Alternatively, what do you want to solve/achieve?

Just curious of course if you don't mind please.

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

Re: NTP server with System z for PCI-DSS compliance

2013-09-12 Thread Timothy Sipples

Shmuel Metz writes:
The criticism is *not* that STP has a separate charge, but rather that
the automated setting of the time *ON A SINGLE BOX* requires STP,
which is chargeable. I don't recall anybody complaining that
sub-millisecond synchronization between boxes should be free.

OK, so that's where you'd like to draw the no additional
charge/separately chargeable line. I happen to be personally sympathetic
to your viewpoint. Please also make your friendly IBM representative aware
of your views.

Be careful what you wish for, though. As I pointed out there's a
financial impact if that charge line moves. That is, every zEnterprise
machine would increase in price (or decrease less in price). I have no idea
how big the impact would be. Right now there is the option -- typically on
non-production machines -- to not pay anything for STP in any form. You can
choose whether you want to pay for the feature or not. That's financially
more flexible, if nothing else.

There's also the argument that if something is included at no additional
charge then it could be financially tougher for someone else to come along
to build a better mousetrap.

Yes, I'm personally sympathetic to moving that line in the way you suggest,
but I'm trying to present all arguments.

As always here, I'm expressing my own views and not necessarily those of my
employer, my wife, or my barber.


Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: TSO Delete in IKJTSOxx

Lindy Mayfield wrote:

I am curious why sometimes I see DEL/DELETE as an authorized command in 
IKJTSOxx and sometimes not. 

Probably carried over from disused (?) CSECTS like IKJEFTE2, IKJEFTE8, 
IKJEFTAP, and IKJEFTNS?

I don't see it in my CPAC install, but I've seen it pop up in other systems.  

Neither me. Just make sure those DEL/DELETE are not confused with RACF commands 
with similar names.

The reason I ask is because sometimes I want to use /bin/tso to do a DELETE, 
but it fails.  Of course the solution is to either use /bin/tsocmd or take DEL 
out.  I'm just curious why it is there.

Or they were commands in some 3rth party products?

Check your ISRDDN to see if you see DEL/DELETE in some strange libs.

Just a wild speculating on my side! :-)

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

Re: IEE313I when varying a console online

In
c11ded818b17214792b97fba28712bed171b2d0...@jer-email1.jer.ad.malam.com,
on 09/11/2013
   at 06:35 PM, ÔÒÚ ß  ÓßÚ gad...@malam.com said:

When I try to vary the device (V xxx,console)

What is the status when you do a D U? Have you defined it as a console
on that system?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Teletypewriter Model 33

In 0711121653687111.wa.paulgboulderaim@listserv.ua.edu, on
09/11/2013
   at 11:00 AM, Paul Gilmartin paulgboul...@aim.com said:

Sometimes it appears that you deliberately over-prune quoted material
so you can refute something the previous poster never said. 

I have no doubt that it appears so to people who don't understand what
I wrote, or to people who write ambiguous text and fault others for
not guessing the correct meaning.

It was my program 

Then why the nonsense about EDIT? And how does it have anything do
do with any suggestion of mine? (What you suggest is more like batch
than interactive.)

And editing a file to supply as input to a program rather than
replying to prompts with a terminal makes the operation of that
program more batch-like than interactive, 

A program that is not written to do standard terminal I/O is already
batch; I don't see how using EDIT to prepare input (which I *didn't*
suggest in the first place) could make it any more batch like.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: IEE313I when varying a console online

In
c11ded818b17214792b97fba28712bed171b2d0...@jer-email1.jer.ad.malam.com,
on 09/11/2013
   at 08:49 PM, gad...@malam.com said:

Is is defined in the consolexx member.

Did you IPL since chsnging the CONSOLxx member? Are you sure that you
are using that member?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: 1403 Printer components manual GA24-3073-3

In 2105594249840396.wa.paulgboulderaim@listserv.ua.edu, on
09/11/2013
   at 02:57 PM, Paul Gilmartin paulgboul...@aim.com said:

WAD?  For shame!

Damaging the ribbon is nothing. I've been told that on the original
1403, forcing a print check by firing the hammers at the maximum rate
could break the chain.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Currently dispatched TCB in SRB mode

In
off734f566.cc66f421-on85257be4.00037347-85257be4.0003f...@us.ibm.com,
on 09/11/2013
   at 08:43 PM, Jim Mulder d10j...@us.ibm.com said:

Then a Bind Break is done

Thanks.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: PDS/E, Shared Dasd, and COBOL V5

In 20130912071242.3bfa3fc8d897d3c140761...@gmx.net, on 09/12/2013
   at 07:12 AM, nitz-...@gmx.net nitz-...@gmx.net said:

Have that application call an authorized command or program (iebcopy
will suffice) on at least two processors/tcbs at the same time. 

How? Won't the TMP set you nondispatchable until the authorized
command completes?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Currently dispatched TCB in SRB mode

In 5mr239lukvqm4q0ijvvv6f2o1tp2cul...@4ax.com, on 09/12/2013
   at 10:39 AM, Binyamin Dissen bdis...@dissensoftware.com said:

As Jim pointed out, obviously the other processor cannot free these
areas until all processors acknowledge the attempt.

It wasn't obvious until he told us about the shoulder tap and spin
loop.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: PDS/E, Shared Dasd, and COBOL V5


On 9/12/2013 1:53 AM, Timothy Sipples wrote:

I cracked open a (metaphorical) history book, and I discovered that IBM
introduced PDSEs in 1989 -- about 24 years ago as I write this.

I agree with John Gilmore. A 2013 PDSE prerequisite for Enterprise COBOL
5.1 is not too soon.

I should point out that IBM announced no charge 90-day trials of CICS
Transaction Server 5.1 and Enterprise COBOL 5.1. You can try these products
for 90 days without worrying about single version charge (SVC) periods. You
can confirm how much more efficiently your CPU-intensive COBOL applications
run after recompiling, for example. You can also get acquainted with PDSEs
and their impacts. (Did I actually just write that? :-))

By the way, I *frequently* encounter customers that don't submit SCRT
reports with Enterprise COBOL correctly associated only with the LPARs
where they run it. IBM receives SCRT reports where Enterprise COBOL is
assumed to be running in every z/OS LPAR, and then IBM bills accordingly.
(Thanks for that.) But Enterprise COBOL 5.1 now generates its very own Type
89 SMF records so you don't have to be aware of NO89 (many aren't) and
don't have to worry about it. Hurray for that too.

Give the products a spin and kick the tires, at no additional charge.
You'll probably like them very much. Unless perhaps you're the person John
Gilmore is describing. :-)



Tim,

All due respect, the cost to IBM's customer base for converting all 
COBOL executable libraries to PDSE will be measured in millions, if not 
billions, of US dollars.  This decision to require COBOL V5.1 
executables only in a PDSE has extreme negative ramifications for every 
COBOL shop on the planet.  I have no understanding of IBM's thought 
process here.


DFSMS is also rolling out PDSE V2, in order to correct some of the 
shortcomings that have existed in PDSE from day 1.  You are correct that 
PDSE has been around for 24 years, but to this day, PDSE STILL generates 
Sev 1 problems!  A PDSE prerequisite for COBOL should NEVER have 
happened, given the current state of PDSE.  A conversion to PDSE V2 is 
going to be difficult enough, let alone converting all COBOL executables 
to PDSE.


This was a poor decision by IBM.

Regards,
Tom Conley

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

Re: NTP server with System z for PCI-DSS compliance

In
of811b14da.8838eb3f-on48257be4.0035cc4f-48257be4.00386...@sg.ibm.com,
on 09/12/2013
   at 06:14 PM, Timothy Sipples sipp...@sg.ibm.com said:

OK, so that's where you'd like to draw the no additional
charge/separately chargeable line.

I can see several possibilities. In order of preference:

 1. Using NTP to set the TOD forward by a small amount.

 2. Using NTP to set a virtual TOD forward by a small amount.

 3. Using NTP to set the TOD at the next POR.

Note that I am not suggesting the ability to set the TOD backwards,
nor do I consider it desirable to use clock steering to correct major
discrepancies unless an IPL is totally unacceptable.

Have their been any discussions at Share about this issue? I assume
that it's only the small shops that would be interested; the large
ones presumably need STP due to multi-CEC configurations.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: TSO Delete in IKJTSOxx

2013-09-12 Thread Bob Shannon

I am curious why sometimes I see DEL/DELETE as an authorized command in 
IKJTSOxx and sometimes not.

Being a development shop we have everything under the sun in IKJTSOxx, but not 
DEL.

Bob Shannon
Rocket Software

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

Re: PDS/E, Shared Dasd, and COBOL V5

Tom Conley wroter:

begin extract
All due respect, the cost to IBM's customer base for converting all
COBOL executable libraries to PDSE will be measured in millions, if
not billions, of US dollars.
/end extract

[With] all due respect again, this is empty rhetoric.  The last
Decennial Census,  of 2010, yielded a US population aged 5-17 of
53,980,105.  Let us now assume, conservatively, that the members of
this group spent an arithmetic mean of US$1.00 per week on junk food
in 2010.

The 'alarming' result?  This group spent US$2,806,965,460 on junk food
in 2010!   'Almost' 3 billion dollars wasted!  Etc., etc.  The
context-free large-numbers gambit is an old one, but it persuades only
the already persuaded.

John Gilmore, Ashland, MA 01721 - USA

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

Re: PDS/E, Shared Dasd, and COBOL V5


On 9/12/2013 8:12 AM, John Gilmore wrote:

Tom Conley wroter:

begin extract
All due respect, the cost to IBM's customer base for converting all
COBOL executable libraries to PDSE will be measured in millions, if
not billions, of US dollars.
/end extract

[With] all due respect again, this is empty rhetoric.  The last
Decennial Census,  of 2010, yielded a US population aged 5-17 of
53,980,105.  Let us now assume, conservatively, that the members of
this group spent an arithmetic mean of US$1.00 per week on junk food
in 2010.

The 'alarming' result?  This group spent US$2,806,965,460 on junk food
in 2010!   'Almost' 3 billion dollars wasted!  Etc., etc.  The
context-free large-numbers gambit is an old one, but it persuades only
the already persuaded.

John Gilmore, Ashland, MA 01721 - USA

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


So there's no cost whatsoever to IBM's customer base for converting 
COBOL executable libraries from PDS to PDSE?  My mistake.


Here are some context-free, large-numbers gambit empty rhetoric numbers. 
 Let's assume 1000 COBOL licenses in the world, with 100 executable 
datasets per license (IMNSHO, ridiculously conservative estimates).  So 
that's 100,000 executable datasets.  I'll set, again, a conservative 
estimate of $1,000 to convert the PDS to PDSE.  Here is how I break that 
down.  Planning - 1 hour.  Allocating and copying - 1 hour.  Change 
control paperwork - 2 hours.  Implementation - 2 hours. 
Post-implementation followup - 2 hours.  That's 8 hours at a 
fully-burdened rate of $125/hr.  I haven't even figured in the cost of 
DASD.  That's $100M US just to convert this small scenario I've laid out 
here.


This is the last time I'll ever respond to a post by John Gilmore.

Regards,
Tom Conley

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

Re: TSO Delete in IKJTSOxx


On 9/12/2013 3:43 AM, Lindy Mayfield wrote:

I am curious why sometimes I see DEL/DELETE as an authorized command in 
IKJTSOxx and sometimes not.  I don't see it in my CPAC install, but I've seen 
it pop up in other systems.  The reason I ask is because sometimes I want to 
use /bin/tso to do a DELETE, but it fails.  Of course the solution is to either 
use /bin/tsocmd or take DEL out.  I'm just curious why it is there.

Thanks!
Lindy




Lindy,

I've run into this in the past when deleting GDG bases from ISPF 3.4.  I 
get an authorization failed message, and putting DELETE in IKJTSO00 and 
a PARMLIB UPDATE(00) fixes it.


Regards,
Tom Conley

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

Re: PDS/E, Shared Dasd, and COBOL V5

Tom,

I might suggest you underestimated the outage time and costs.  For the
compiler and source management software - probably 2 hours.

But to change out all of the load libraries into PDS/E datasets - much
longer.  

That will impact any function in z/OS that runs production code.  So assume
that joblibs/steplibs in any DB2 Stored procedure, CICS STC DFHREPL, IMS
STCs DFSRESLB, MQ STCs, and all batch JCL have to change.  That outage could
a huge impact.

I do not see the conversion from PDS to PDS/E big if all rules are followed.
But if I have an application load library that needs to be changed from PDS
to PDS/E that is in all of the above mentioned JCL, then I have to have
everything come down on all systems at one time.  That could be a much
longer window and almost a Plex wide outage.

Yes, one could start by putting in an empty PDS/E above the PDS in all of
the above mentioned JCL and then over time get things straightened out.  I
could not start loading that PDS/E until all the application JCL has also
had it added.  

Yet, even with a pre-staging of the PDS/E into the JCL.  Our shop, for
example, has not cycled some of these types of tasks for over 4 months.  Our
time line to change to PDS/E in these tasks (CICS, IMS, MQ, DB2, etc...)
would be at least 6 months or so for a normal process.  To cycle these tasks
sooner could take an act of some deity.  

For the application group much longer to start changing all of their
steplibs and joblibs.  They have more work, because, even if it is a benign
change like adding one DD statement to the steplib/joblib - that JCL has to
go through all the normal checkout processes.  QA, Unit test, Validation,
change control, etc   That could take up to a year or so; however, if
you have 60k or so product batch JCL (and you do not know which ones are
really live), it could take even longer.  Therefore, until all the
application JCL has been updated, the STCs would continue to have an empty
PDS/E dataset.  That is where I see the issue.

So one version of this plan, how change all PDS to PDS/E for load modules,
would be to start with forcing the Change Management Software to include an
empty PDS/E into all JCL that goes through it for steplib and joblib.
System folks would start by placing the same empty PDS/E into the JCL they
manage.  Lastly the shop's management would need to assign a group of
application folks to focus on review and changing the remaining JCL for
production.  It will be almost like a Y2K effort.  There would also need to
be an analysis of how many PDS/E Datasets will be needed.  

As some applications will have unique PDSs for their applications so tasks
like the CICS DFHRPL may not have 1 PDS for application load modules but
MULTIPLE PDS datasets.  And your storage admin folks will also need to be
involved as some load libraries are huge and there would need to be two of
everything until the conversions complete - 1 PDS (current) 1 PDS/E - future
replacement.


Just my $0.02 worth.

Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Thomas Conley
Sent: Thursday, September 12, 2013 5:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDS/E, Shared Dasd, and COBOL V5

On 9/12/2013 8:12 AM, John Gilmore wrote:
 Tom Conley wroter:

 begin extract
 All due respect, the cost to IBM's customer base for converting all 
 COBOL executable libraries to PDSE will be measured in millions, if 
 not billions, of US dollars.
 /end extract

 [With] all due respect again, this is empty rhetoric.  The last 
 Decennial Census,  of 2010, yielded a US population aged 5-17 of 
 53,980,105.  Let us now assume, conservatively, that the members of 
 this group spent an arithmetic mean of US$1.00 per week on junk food 
 in 2010.

 The 'alarming' result?  This group spent US$2,806,965,460 on junk food
 in 2010!   'Almost' 3 billion dollars wasted!  Etc., etc.  The
 context-free large-numbers gambit is an old one, but it persuades only 
 the already persuaded.

 John Gilmore, Ashland, MA 01721 - USA

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

So there's no cost whatsoever to IBM's customer base for converting COBOL
executable libraries from PDS to PDSE?  My mistake.

Here are some context-free, large-numbers gambit empty rhetoric numbers. 
  Let's assume 1000 COBOL licenses in the world, with 100 executable
datasets per license (IMNSHO, ridiculously conservative estimates).  So
that's 100,000 executable datasets.  I'll set, again, a conservative
estimate of $1,000 to convert the PDS to PDSE.  Here is how I break that
down.  Planning - 1 hour.  Allocating and copying - 1 hour.  Change control
paperwork - 2 hours.  Implementation - 2 hours. 
Post-implementation followup - 2 hours.  That's 8 hours at a fully-burdened
rate of $125/hr.  I

Re: TSO Delete in IKJTSOxx

Thomas Conley wrote:

I've run into this in the past when deleting GDG bases from ISPF 3.4.  I get 
an authorization failed message, and putting DELETE in IKJTSO00 and a PARMLIB 
UPDATE(00) fixes it.

Interesting. This is new for me or I forgot about it. :-)

Could you be kind to say what that message was? Was it a RACF message on the 
profile covering the GDG, Catalog or was it about STGADMIN.IGG.DELGDG.RECOVERY? 
Or something else?

Or what was the actual command running under the covers?

Just curious if you don't mind please.

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

Re: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Schumacher, Otto

What is the downtime when a PDS has to be compressed?  We have eliminated the 
downtimes for PDS compressions by using PDSE.  We have not had any problems 
attributed to PDSE's since we changed the loadlibs from PDS to PDSE. 

Regards
Otto H Schumacher
Transaction and Database Systems - CICS Specialist
U. S. Mainframe 
HP Enterprise Services 
Telephone +1 864 987 1417 
Mobile +1 864 569 5338 
Email otto.schumac...@hp.com 



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, September 12, 2013 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDS/E, Shared Dasd, and COBOL V5

Tom,

I might suggest you underestimated the outage time and costs.  For the compiler 
and source management software - probably 2 hours.

But to change out all of the load libraries into PDS/E datasets - much longer.  

That will impact any function in z/OS that runs production code.  So assume 
that joblibs/steplibs in any DB2 Stored procedure, CICS STC DFHREPL, IMS STCs 
DFSRESLB, MQ STCs, and all batch JCL have to change.  That outage could a huge 
impact.

I do not see the conversion from PDS to PDS/E big if all rules are followed.
But if I have an application load library that needs to be changed from PDS to 
PDS/E that is in all of the above mentioned JCL, then I have to have everything 
come down on all systems at one time.  That could be a much longer window and 
almost a Plex wide outage.

Yes, one could start by putting in an empty PDS/E above the PDS in all of the 
above mentioned JCL and then over time get things straightened out.  I could 
not start loading that PDS/E until all the application JCL has also had it 
added.  

Yet, even with a pre-staging of the PDS/E into the JCL.  Our shop, for example, 
has not cycled some of these types of tasks for over 4 months.  Our time line 
to change to PDS/E in these tasks (CICS, IMS, MQ, DB2, etc...) would be at 
least 6 months or so for a normal process.  To cycle these tasks sooner could 
take an act of some deity.  

For the application group much longer to start changing all of their steplibs 
and joblibs.  They have more work, because, even if it is a benign change like 
adding one DD statement to the steplib/joblib - that JCL has to go through all 
the normal checkout processes.  QA, Unit test, Validation,
change control, etc   That could take up to a year or so; however, if
you have 60k or so product batch JCL (and you do not know which ones are really 
live), it could take even longer.  Therefore, until all the application JCL has 
been updated, the STCs would continue to have an empty PDS/E dataset.  That is 
where I see the issue.

So one version of this plan, how change all PDS to PDS/E for load modules, 
would be to start with forcing the Change Management Software to include an 
empty PDS/E into all JCL that goes through it for steplib and joblib.
System folks would start by placing the same empty PDS/E into the JCL they 
manage.  Lastly the shop's management would need to assign a group of 
application folks to focus on review and changing the remaining JCL for 
production.  It will be almost like a Y2K effort.  There would also need to be 
an analysis of how many PDS/E Datasets will be needed.  

As some applications will have unique PDSs for their applications so tasks like 
the CICS DFHRPL may not have 1 PDS for application load modules but MULTIPLE 
PDS datasets.  And your storage admin folks will also need to be involved as 
some load libraries are huge and there would need to be two of everything until 
the conversions complete - 1 PDS (current) 1 PDS/E - future replacement.


Just my $0.02 worth.

Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Thomas Conley
Sent: Thursday, September 12, 2013 5:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDS/E, Shared Dasd, and COBOL V5

On 9/12/2013 8:12 AM, John Gilmore wrote:
 Tom Conley wroter:

 begin extract
 All due respect, the cost to IBM's customer base for converting all 
 COBOL executable libraries to PDSE will be measured in millions, if 
 not billions, of US dollars.
 /end extract

 [With] all due respect again, this is empty rhetoric.  The last 
 Decennial Census,  of 2010, yielded a US population aged 5-17 of 
 53,980,105.  Let us now assume, conservatively, that the members of 
 this group spent an arithmetic mean of US$1.00 per week on junk food 
 in 2010.

 The 'alarming' result?  This group spent US$2,806,965,460 on junk food
 in 2010!   'Almost' 3 billion dollars wasted!  Etc., etc.  The
 context-free large-numbers gambit is an old one, but it persuades only 
 the already persuaded.

 John Gilmore, Ashland, MA 01721 - USA

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

So

Re: Currently dispatched TCB in SRB mode

2013-09-12 Thread Binyamin Dissen

On Thu, 12 Sep 2013 07:35:20 -0400 Shmuel Metz (Seymour J.)
shmuel+...@patriot.net wrote:

:In 5mr239lukvqm4q0ijvvv6f2o1tp2cul...@4ax.com, on 09/12/2013
:   at 10:39 AM, Binyamin Dissen bdis...@dissensoftware.com said:

:As Jim pointed out, obviously the other processor cannot free these
:areas until all processors acknowledge the attempt.

:It wasn't obvious until he told us about the shoulder tap and spin
:loop.

As the data is available to other processors, it was obvious to me that
changes could not be made unilaterally.

--
Binyamin Dissen bdis...@dissensoftware.com
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

Re: TSO Delete in IKJTSOxx

2013-09-12 Thread nitz-...@gmx.net

 I've run into this in the past when deleting GDG bases from ISPF 3.4.  I get 
 an authorization failed message, and putting DELETE in IKJTSO00 and a 
 PARMLIB UPDATE(00) fixes it.
 
 Interesting. This is new for me or I forgot about it. :-)

I found this interesting, too, so I went and tried it out. Discovered first 
that the active IKJTSO member is not compliant with the one in samplib (typical 
for ADCD!), and that we had delete in it, too. Removed delete from the authcmds 
and still didn't get any error messages, RACF or otherwise when I deleted an 
empty GDG base.

 Could you be kind to say what that message was? Was it a RACF message on the 
 profile covering the GDG, Catalog or was it about 
 STGADMIN.IGG.DELGDG.RECOVERY? Or something else?
Yes, that would be interesting, since I gave myself ALTER authority to just 
about everything since I am supposed to be both RACF and space admin.

Barbara Nitz

PS: Now I am checking what we actually have in IKJTSO as opposed to what we 
should have in there according to sys1.samplib.

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

Re: TSO Delete in IKJTSOxx

2013-09-12 Thread Rob Scott

Take a look at IBM APAR II09867

Explains why some sites have moved DELETE into AUTHCMD 

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of nitz-...@gmx.net
Sent: 12 September 2013 14:21
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO Delete in IKJTSOxx

 I've run into this in the past when deleting GDG bases from ISPF 3.4.  I get 
 an authorization failed message, and putting DELETE in IKJTSO00 and a 
 PARMLIB UPDATE(00) fixes it.
 
 Interesting. This is new for me or I forgot about it. :-)

I found this interesting, too, so I went and tried it out. Discovered first 
that the active IKJTSO member is not compliant with the one in samplib (typical 
for ADCD!), and that we had delete in it, too. Removed delete from the authcmds 
and still didn't get any error messages, RACF or otherwise when I deleted an 
empty GDG base.

 Could you be kind to say what that message was? Was it a RACF message on the 
 profile covering the GDG, Catalog or was it about 
 STGADMIN.IGG.DELGDG.RECOVERY? Or something else?
Yes, that would be interesting, since I gave myself ALTER authority to just 
about everything since I am supposed to be both RACF and space admin.

Barbara Nitz

PS: Now I am checking what we actually have in IKJTSO as opposed to what we 
should have in there according to sys1.samplib.

--
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: Wait all CPU's enabled at least once

2013-09-12 Thread Jon Perryman

I asked out of curiosity. I wanted to read how it worked. I wondered if it is 
really fast and how it avoided a deadly embrace.

Jon Perryman. 


- Original Message -
 From: Elardus Engelbrecht elardus.engelbre...@sita.co.za
 
 Jon Perryman wrote:
 
 Is there an instruction that waits for all CPU's to be enabled at least 
 once?
 
 I saw Jim's reply and reread my PrOPs, but why do you want all CPU's to 
 be enabled? What type of CPU? 
 
 Alternatively, what do you want to solve/achieve?
 
 Just curious of course if you don't mind please.


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

Re: TSO Delete in IKJTSOxx


On 9/12/2013 9:21 AM, nitz-...@gmx.net wrote:

I've run into this in the past when deleting GDG bases from ISPF 3.4.  I get an 
authorization failed message, and putting DELETE in IKJTSO00 and a PARMLIB 
UPDATE(00) fixes it.


Interesting. This is new for me or I forgot about it. :-)


I found this interesting, too, so I went and tried it out. Discovered first 
that the active IKJTSO member is not compliant with the one in samplib (typical 
for ADCD!), and that we had delete in it, too. Removed delete from the authcmds 
and still didn't get any error messages, RACF or otherwise when I deleted an 
empty GDG base.


Could you be kind to say what that message was? Was it a RACF message on the 
profile covering the GDG, Catalog or was it about STGADMIN.IGG.DELGDG.RECOVERY? 
Or something else?

Yes, that would be interesting, since I gave myself ALTER authority to just 
about everything since I am supposed to be both RACF and space admin.

Barbara Nitz

PS: Now I am checking what we actually have in IKJTSO as opposed to what we 
should have in there according to sys1.samplib.

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



http://www-01.ibm.com/support/docview.wss?uid=isg3S1000170

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

Re: TSO Delete in IKJTSOxx

2013-09-12 Thread Steve Conway

Barbara, keep in mind that the SAMPLIB IKJTSO reflects a vanilla system. 
 Any Program Products may instruct you to update IKJTSO.

CA ENF, zSecure, OPS/MVS, all have a place in mine.  Along with remnants 
from the past that I hesitate to delete.  :-)


Cheers,,,Steve

Steven F. Conway, CISSP
LA Systems
z/OS Systems Support
Phone: 703.295.1926
steve_con...@ao.uscourts.gov



From:   nitz-...@gmx.net nitz-...@gmx.net
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   09/12/2013 09:21 AM
Subject:Re: TSO Delete in IKJTSOxx
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



 I've run into this in the past when deleting GDG bases from ISPF 3.4. I 
get an authorization failed message, and putting DELETE in IKJTSO00 and a 
PARMLIB UPDATE(00) fixes it.
 
 Interesting. This is new for me or I forgot about it. :-)

I found this interesting, too, so I went and tried it out. Discovered 
first that the active IKJTSO member is not compliant with the one in 
samplib (typical for ADCD!), and that we had delete in it, too. Removed 
delete from the authcmds and still didn't get any error messages, RACF or 
otherwise when I deleted an empty GDG base.

 Could you be kind to say what that message was? Was it a RACF message on 
the profile covering the GDG, Catalog or was it about 
STGADMIN.IGG.DELGDG.RECOVERY? Or something else?
Yes, that would be interesting, since I gave myself ALTER authority to 
just about everything since I am supposed to be both RACF and space admin.

Barbara Nitz

PS: Now I am checking what we actually have in IKJTSO as opposed to what 
we should have in there according to sys1.samplib.

--
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: Wait all CPU's enabled at least once

2013-09-12 Thread DASDBILL2

A potential deadly embrace caused by a disabled spin loop while waiting for 
something else to happen on another processor has already been addressed.  z/OS 
can detect that situation  and ABEND the process that is in the disabled spin 
loop.  If that process happens to be trying to take another processor offline, 
then that process needs to have some recovery logic in place to deal with this 
contingency.  Perhaps stop trying to take the other CPU offline or ask the 
operator are some logical choices. 



A deadly embrace in which both processes are enabled and waiting on each other 
is different. 

Bill Fairchild 
Franklin, TN 


- Original Message -
From: Jon Perryman jperr...@pacbell.net 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, September 12, 2013 9:29:23 AM 
Subject: Re: Wait all CPU's enabled at least once 

I asked out of curiosity. I wanted to read how it worked. I wondered if it is 
really fast and how it avoided a deadly embrace. 

Jon Perryman.  


- Original Message - 
 From: Elardus Engelbrecht elardus.engelbre...@sita.co.za 
  
 Jon Perryman wrote: 
 
 Is there an instruction that waits for all CPU's to be enabled at least 
 once? 
 
 I saw Jim's reply and reread my PrOPs, but why do you want all CPU's to 
 be enabled? What type of CPU? 
 
 Alternatively, what do you want to solve/achieve? 
 
 Just curious of course if you don't mind please. 


-- 
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: IEE313I when varying a console online

2013-09-12 Thread Peter Fatzinger

System command D C,U=xxx will show you if console services believes there is a 
console defined for that device.

There's also a Redbook for the 2074  
(http://www.redbooks.ibm.com/abstracts/sg245966.html) which may help.

Peter Fatzinger

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

Re: NTP server with System z for PCI-DSS compliance

2013-09-12 Thread Joel C. Ewing

On 09/12/2013 06:55 AM, Shmuel Metz (Seymour J.) wrote:
 In
 of811b14da.8838eb3f-on48257be4.0035cc4f-48257be4.00386...@sg.ibm.com,
 on 09/12/2013
at 06:14 PM, Timothy Sipples sipp...@sg.ibm.com said:
 
 OK, so that's where you'd like to draw the no additional
 charge/separately chargeable line.
 
 I can see several possibilities. In order of preference:
 
  1. Using NTP to set the TOD forward by a small amount.
 
  2. Using NTP to set a virtual TOD forward by a small amount.
 
  3. Using NTP to set the TOD at the next POR.
 
 Note that I am not suggesting the ability to set the TOD backwards,
 nor do I consider it desirable to use clock steering to correct major
 discrepancies unless an IPL is totally unacceptable.
 
 Have their been any discussions at Share about this issue? I assume
 that it's only the small shops that would be interested; the large
 ones presumably need STP due to multi-CEC configurations.
 

Forward-only nudging wouldn't be very useful unless the TOD clock was
also deliberately designed to always run a hair slow (is it?).  Perhaps
that can be done and yet have TOD relative accuracy still good enough
for those installations not using any external time synchronization that
need TOD drift to be minimal.

Although conceptually I like the idea of being able to provide a cheaper
NTP option, if you allow z/OS time to jump discontinuously as on UNIX
systems with NTP and that happens very often, you will be introducing
strange anomalies into SMF data that might make it impossible to rely on
measured transaction response times.  I would say proceed with caution.

-- 
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: PDS/E, Shared Dasd, and COBOL V5

I found Mr. Conley's computations interesting.  They presumably
reflect his practices and those of his shop, and what specifically I
found most interesting about them is their manual, handicraft,
repetitive character.

His costing calculations assume that each PDS to PDSE conversion is a
new problem, one that is to be approached, analyzed, and resolved ab
initio.  In fact the entire process is a trivial one that can be, has
been, very largely automated.  Moreover, it should be.  The only
distinctively human contribution that can be made to such repetitive
processes are the errors that are inevitably introduced by fatigue and
 boredom.

Mr Conley vow to abstain from commenting on my posts is drôle.  He is
welcome to comment on them, or not, as he sees fit.

John Gilmore, Ashland, MA 01721 - USA

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

Re: TSO Delete in IKJTSOxx

2013-09-12 Thread Ed Gould


Barbara:

There are *some* commands (IDCAMS) that may still need APF. My  
distant memories it was something to do with del usercatalog or some  
such unusual IDCAMS command.

Wish my memory is sharper here though.

Ed

On Sep 12, 2013, at 6:13 AM, nitz-...@gmx.net wrote:

I am curious why sometimes I see DEL/DELETE as an authorized  
command in IKJTSOxx and sometimes not.
The current (1.13) SYS1.SAMPLIB(IKJTSO00) does not contain del or  
delete in the AUTHCMD section (anymore). If it is still found in a  
productive IKJTSOxx member, my guess is that that is 'hysterically  
grown' and nobody has ever removed it. After a while, nobody dares  
to remove it because 'it might break' something.


Barbara Nitz

--
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 problem (not really), but sort of.

2013-09-12 Thread Joel C. Ewing

On 09/12/2013 01:33 AM, Timothy Sipples wrote:
 John McKown writes:
 But COBOL doesn't have the DWIW (Do What I Want) verb.
 
 We're working on it. :-)
 
 Just be patient and keep smiling, John. You'll get there. Perhaps (as
 another idea) there's already a bit of working, tested, efficient code in
 house that implements substantially the same function the programmer is
 trying to achieve?
 
 
 Timothy Sipples
 GMU VCT Architect Executive (Based in Singapore)
 E-Mail: sipp...@sg.ibm.com
...
It sounded like 80% of the problem was that John was dealing with a
programmer who was satisfied with an approach based on a erroneous
understanding of COBOL semantics and code that gave the appearance of
working some of the time while containing known semantic errors that
guaranteed unpredictable failures.

That is a personnel problem.  Perhaps the individual is inadequately
trained or just mentally unsuited to the rigors of programming.  The
ultimate solution (attitude change and better training, or replacement)
may not be under John's control.


-- 
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: IEE313I when varying a console online

2013-09-12 Thread Bill Bishop (TEMA TPC)

It has been several years since I did these so I had to remember where all this 
info was.

There was a document I found, Usage Tips for the 2074 Console Controller,  
ftp://ftp.software.ibm.com/hardware/p390/doc/2074/GM130316.PDF  that references 
the /con parameter and I put it on all of my console definitions.  
Unfortunately, it apparently refers to recovery capability if the logical 
address is defined as a console.  Not required to be defined as a console.  So 
that is not the issue.

What do the UA and Index fields on the 2074 connection screen display say?  On 
my system, I started my unit addresses at 00, but the index address start at 01 
so my actual MVS unit addresses matched the unit address and not the index 
address.

I know that there are many ways to define the unit addresses on the 2074 and 
they don't have to be even have to be sequential. 

Thanks

Bill Bishop

Specialist
Mainframe Support Group
Server Development  Support
Toyota Motor Engineering  Manufacturing North America, Inc.
bill.bis...@tema.toyota.com
(502) 570-6143


-Original Message-
From: גדי בן אבי [mailto:gad...@malam.com] 
Sent: Thursday, September 12, 2013 12:17 AM
To: IBM Mainframe Discussion List
Cc: Bill Bishop (TEMA TPC)
Subject: RE: IEE313I when varying a console online

Hi Bill,

I haven't seen any mention of a /con parameter in the documentation I have.

Gadi

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Bishop (TEMA TPC)
Sent: Wednesday, September 11, 2013 9:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE313I when varying a console online

Do you have the /con entry in the parameters section of the 2074 definitions 
for the terminal being used as a console?

Thanks

Bill Bishop

Specialist
Mainframe Support Group
Server Development  Support
Toyota Motor Engineering  Manufacturing North America, Inc.
bill.bis...@tema.toyota.com
(502) 570-6143

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ??? ?? ???
Sent: Wednesday, September 11, 2013 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE313I when varying a console online

Hi

The answer is yes to both questions.
I can very it online, but I cannot vary console.
The output from D U is O or OFFLINE.
Is is defined in the consolexx member.

Gadi



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of 
John McKown [john.archie.mck...@gmail.com]
Sent: 11 September 2013 18:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEE313I when varying a console online

Is the address specified exist in the I/O configuration? D U,,,,1 gives 
back valid information. If so, what is it's status? It needs to be OFFLINE 
before it can be varied as a CONSOLE. And it needs to be specified in the 
CONSOLxx member which was specified at IPL time.


On Wed, Sep 11, 2013 at 10:35 AM, גדי בן אבי gad...@malam.com wrote:

 Hi,

 I am in the process of installing a 2074 for a client. I know it's 
 ancient, and unsupported, but everything this client has is ancient 
 and unsupported.

 I managed to get a working console session on the 2074.
 When I try to configure PCOM, I get the 2074 index message.

 When I try to vary the device (V xxx,console) i get:
 IEE313I UNIT REF. INVALID.

 What can the reason for this be?
 How do I fix it.

 The machine is a 2074 model 3
 The computer is a 9672-R14
 OS is OS/390 v2.8.

 Thanks



 
 לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או 
 מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, 
 הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך 
 כאמור (לרבות מסמך
 סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום 
 טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.


 Please note that in accordance with Malam's signatory rights, no 
 offer, agreement, concession or representation is binding on the 
 company, unless accompanied by a duly signed separate document (or a 
 scanned version thereof), affixed with the company's seal.

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




--
As of next week, passwords will be entered in Morse code.

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: NTP server with System z for PCI-DSS compliance

2013-09-12 Thread Skip Robinson

While the most obvious value of STP may be synchronization of multiple z 
CECs in a glass house, it is invaluable for synchronizing all z CECs with 
the rest of the enterprise. Like many shops, we have a boatload of Unix 
and x86 servers that all participate in running the business in concert 
with each other. STP allows us to synchronize z with the standard 
corporate NTP time server in both multi- and single-CEC environments. We 
never could do that with the old sysplex timers. 

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



From:   Joel C. Ewing jcew...@acm.org
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   09/12/2013 07:08 AM
Subject:Re: NTP server with System z for PCI-DSS compliance
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



On 09/12/2013 06:55 AM, Shmuel Metz (Seymour J.) wrote:
 In
 of811b14da.8838eb3f-on48257be4.0035cc4f-48257be4.00386...@sg.ibm.com,
 on 09/12/2013
at 06:14 PM, Timothy Sipples sipp...@sg.ibm.com said:
 
 OK, so that's where you'd like to draw the no additional
 charge/separately chargeable line.
 
 I can see several possibilities. In order of preference:
 
  1. Using NTP to set the TOD forward by a small amount.
 
  2. Using NTP to set a virtual TOD forward by a small amount.
 
  3. Using NTP to set the TOD at the next POR.
 
 Note that I am not suggesting the ability to set the TOD backwards,
 nor do I consider it desirable to use clock steering to correct major
 discrepancies unless an IPL is totally unacceptable.
 
 Have their been any discussions at Share about this issue? I assume
 that it's only the small shops that would be interested; the large
 ones presumably need STP due to multi-CEC configurations.
 

Forward-only nudging wouldn't be very useful unless the TOD clock was
also deliberately designed to always run a hair slow (is it?).  Perhaps
that can be done and yet have TOD relative accuracy still good enough
for those installations not using any external time synchronization that
need TOD drift to be minimal.

Although conceptually I like the idea of being able to provide a cheaper
NTP option, if you allow z/OS time to jump discontinuously as on UNIX
systems with NTP and that happens very often, you will be introducing
strange anomalies into SMF data that might make it impossible to rely on
measured transaction response times.  I would say proceed with caution.

-- 
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: Teletypewriter Model 33

2013-09-12 Thread Paul Gilmartin

On 2013-09-12, at 05:03, Shmuel Metz (Seymour J.) wrote:
 
   at 11:00 AM, Paul Gilmartin said:
 
 Sometimes it appears that you deliberately over-prune quoted material
 so you can refute something the previous poster never said. 
 ...
 A program that is not written to do standard terminal I/O is already
 batch; I don't see how using EDIT to prepare input (which I *didn't*
 suggest in the first place) could make it any more batch like.
  
Ahem:

On Mon, 9 Sep 2013 21:03:03 -0400, Shmuel Metz wrote:

Try ALLOCATE DD(SYSIN) DSN(*)

Why would I do that for an interactive command? Try EDIT foo.text.

That meets my understanding of suggest.

-- gil

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

Makes you go hmmmm, EVA MSU of 21 Cyls

2013-09-12 Thread Chip Grantham

I've finally taken the time to try to understand the numbers behind the way 
EAVs were implemented.  I found a great discussion in the redbook z/OS v1.12 
Implimentation  SG24-7853-00 manual, chapter 20.  Any time spend you happen to 
spend here is worth it. (not unlike all redbooks).   Thanks to those that wrote 
it. 

I did happen into a segment that makes me go hmmm.  20.4.3 Multicylinder unit 
section says the 21-cylinder value for the MCU is derived from being the 
smallest unit that can map out the largest possible EAV and stay within the 
index architecture (with a block size of 8192), as follows: 
* It is also a value that divides evenly into the 1 GB storage segments of an 
IBM DS8000, 
* These 1 GB segments are the allocation unit in the IBM DS8000 and are 
equivalent to 1,113 cylinders. 

I'm sure the index architecture references the index vtoc architecture, which 
has always been a curious archeture to me.  Has this design ever been made 
open?  Just curious as to why it made 21 the magic number? 

I also ran into a math issue when I divided 21 into 1GB (or 1,073,741,824/21 = 
51,130,563.0476...).  I suspect that's because the 1GB storage segment is a 
number used in the DS8000 degisn, and its really close to the 1GB value. 
Wondering if that's true or some other reason.   

Just makes me go hmmm.

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

Re: ACS routine trace.

2013-09-12 Thread Darth Keller

I'm curious.  Do you ever use the NaviQuest SMS test facility?
ddk






But first I must trigger some trace data. I found there is an SMS trace,
but I wonder if this produces much more than I need.

I found a replacement for the WRITE-trace mechanism: I defined a Storage
Class that is not used and at the point that I needed the WRITE trace
info, I set the SC to this specific SC. By moving this piece of code to
different decision points in the SC routine, I found the place where it
made the wrong decision.

I could define several trace-SCs and at point 1 set SC1, at point 2 set
SC2 etc. Thus one can determine which code was executed. A little bit
complicated, but an adequate replacement for the missing WRITE
information.

Kees.

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

Re: ACS routine trace.

2013-09-12 Thread Vernooij, CP - SPLXM

But first I must trigger some trace data. I found there is an SMS trace,
but I wonder if this produces much more than I need.

I found a replacement for the WRITE-trace mechanism: I defined a Storage
Class that is not used and at the point that I needed the WRITE trace
info, I set the SC to this specific SC. By moving this piece of code to
different decision points in the SC routine, I found the place where it
made the wrong decision.

I could define several trace-SCs and at point 1 set SC1, at point 2 set
SC2 etc. Thus one can determine which code was executed. A little bit
complicated, but an adequate replacement for the missing WRITE
information.

Kees.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Thursday, September 12, 2013 11:04
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ACS routine trace.

At z/OS V1.7 and above (I think) you use IPCS to unload the trace data.

VERBX SMSDATA 'TRACE'

Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Thursday, September 12, 2013 1:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ACS routine trace.

You might try this url

https://www-304.ibm.com/support/docview.wss?uid=isg3S1000411

Problems with ACS routines and how to set an ACS trace

I am not sure how to pull the ACS Trace and read it after it is
collected.

I like a tool called SMSDEBUG for this, but that is a purchase.

Lizette

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Vernooij, CP - SPLXM
Sent: Thursday, September 12, 2013 1:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ACS routine trace.

Hello,

 

I have an problem in my StorClas ACS routine, which I cannot put my
finger on. 

The routine is suspected to not assign a Storclas to an allocation
request, which causes the request to fail. However I cannot find if it
really does and if so, why. WRITE commands are useless, because these
messages will never be displayed if the allocation is done by dynamic
allocation, which is the case here.

 

Is there any other way to find out what my StorClas routine does and
decides?

 

Thanks,

Kees.

 

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

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

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



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

Re: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Greg Shirey

Tom is an independent consultant and a frequent contributor to SHARE.  I feel 
comfortable assuming that he is using his experiences at multiple shops to 
formulate his computations.  

While the process of converting a PDS to a PDSE is indeed trivial, what happens 
after may not be so.  I know my CIO would want assurances that this process 
would not disrupt our business at all.  I might automate the actual conversion, 
but I would spend a whole lot of time testing first and monitoring it 
afterwards.  

Another area that would concern me is interfacing with ISV products.  Most of 
them (at my shop anyway) still distribute load modules in PDSs, and many of 
them require compiling COBOL exit programs to configure some functionality.  Do 
I convert their PDSs to PDSEs so I can use COBOL 5.1 to recompile their exits, 
or do I concatenate loadlibs in the started tasks?  Sounds like a lot more 
testing to me. 

Greg Shirey
Ben E. Keith Company 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Thursday, September 12, 2013 9:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDS/E, Shared Dasd, and COBOL V5

I found Mr. Conley's computations interesting.  They presumably
reflect his practices and those of his shop, and what specifically I
found most interesting about them is their manual, handicraft,
repetitive character.

His costing calculations assume that each PDS to PDSE conversion is a
new problem, one that is to be approached, analyzed, and resolved ab
initio.  In fact the entire process is a trivial one that can be, has
been, very largely automated.  Moreover, it should be.  The only
distinctively human contribution that can be made to such repetitive
processes are the errors that are inevitably introduced by fatigue and
 boredom.

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

Re: PDS/E, Shared Dasd, and COBOL V5


On 9/12/2013 9:03 AM, Lizette Koehler wrote:

Tom,

I might suggest you underestimated the outage time and costs.  For the
compiler and source management software - probably 2 hours.

But to change out all of the load libraries into PDS/E datasets - much
longer.

That will impact any function in z/OS that runs production code.  So assume
that joblibs/steplibs in any DB2 Stored procedure, CICS STC DFHREPL, IMS
STCs DFSRESLB, MQ STCs, and all batch JCL have to change.  That outage could
a huge impact.

I do not see the conversion from PDS to PDS/E big if all rules are followed.
But if I have an application load library that needs to be changed from PDS
to PDS/E that is in all of the above mentioned JCL, then I have to have
everything come down on all systems at one time.  That could be a much
longer window and almost a Plex wide outage.

Yes, one could start by putting in an empty PDS/E above the PDS in all of
the above mentioned JCL and then over time get things straightened out.  I
could not start loading that PDS/E until all the application JCL has also
had it added.

Yet, even with a pre-staging of the PDS/E into the JCL.  Our shop, for
example, has not cycled some of these types of tasks for over 4 months.  Our
time line to change to PDS/E in these tasks (CICS, IMS, MQ, DB2, etc...)
would be at least 6 months or so for a normal process.  To cycle these tasks
sooner could take an act of some deity.

For the application group much longer to start changing all of their
steplibs and joblibs.  They have more work, because, even if it is a benign
change like adding one DD statement to the steplib/joblib - that JCL has to
go through all the normal checkout processes.  QA, Unit test, Validation,
change control, etc   That could take up to a year or so; however, if
you have 60k or so product batch JCL (and you do not know which ones are
really live), it could take even longer.  Therefore, until all the
application JCL has been updated, the STCs would continue to have an empty
PDS/E dataset.  That is where I see the issue.

So one version of this plan, how change all PDS to PDS/E for load modules,
would be to start with forcing the Change Management Software to include an
empty PDS/E into all JCL that goes through it for steplib and joblib.
System folks would start by placing the same empty PDS/E into the JCL they
manage.  Lastly the shop's management would need to assign a group of
application folks to focus on review and changing the remaining JCL for
production.  It will be almost like a Y2K effort.  There would also need to
be an analysis of how many PDS/E Datasets will be needed.

As some applications will have unique PDSs for their applications so tasks
like the CICS DFHRPL may not have 1 PDS for application load modules but
MULTIPLE PDS datasets.  And your storage admin folks will also need to be
involved as some load libraries are huge and there would need to be two of
everything until the conversions complete - 1 PDS (current) 1 PDS/E - future
replacement.


Just my $0.02 worth.

Lizette



snip

   Let's assume 1000 COBOL licenses in the world, with 100 executable
datasets per license (IMNSHO, ridiculously conservative estimates).  So
that's 100,000 executable datasets.  I'll set, again, a conservative
estimate of $1,000 to convert the PDS to PDSE.  Here is how I break that
down.  Planning - 1 hour.  Allocating and copying - 1 hour.  Change control
paperwork - 2 hours.  Implementation - 2 hours.
Post-implementation followup - 2 hours.  That's 8 hours at a fully-burdened
rate of $125/hr.  I haven't even figured in the cost of DASD.  That's $100M
US just to convert this small scenario I've laid out here.

This is the last time I'll ever respond to a post by John Gilmore.

Regards,
Tom Conley



Lizette,

Great analysis of some of the operational costs involved in this PDS to 
PDSE conversion just to support COBOL V5.1.  In many shops, this will 
not be a trivial exercise, as some on IBM-Main have stated.  This will 
be a serious migration effort, and cost significant dollars.  I'm still 
mystified as to why IBM felt it had to impose this completely 
unnecessary restriction.  What reason is there to force COBOL V5.1 
executables to come from a PDSE?


Regards,
Tom Conley

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

Re: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Tom Marchant

On Thu, 12 Sep 2013 17:45:05 +0800, Timothy Sipples wrote:

IThat's precisely why I recommend taking up IBM
on the trial offer, to figure out the impacts in your environment. Most of
them will probably be very welcome impacts, but maybe not all.

A small trial may or may not be useful.  If only a small set of test libraries 
need 
to be converted to PDSE, there may not be any issues at all, especially if all 
of 
the testing is done on a development LPAR.

-- 
Tom Marchant

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

Re: Makes you go hmmmm, EVA MSU of 21 Cyls

2013-09-12 Thread R.S.

W dniu 2013-09-12 16:13, Chip Grantham pisze:

I've finally taken the time to try to understand the numbers behind the way EAVs were
implemented. I found a great discussion in the redbook z/OS v1.12
Implimentation SG24-7853-00 manual, chapter 20. Any time spend you happen to
spend here is worth it. (not unlike all redbooks). Thanks to those that wrote it.

I did happen into a segment that makes me go hmmm. 20.4.3 Multicylinder unit
section says the 21-cylinder value for the MCU is derived from being the
smallest unit that can map out the largest possible EAV and stay within the
index architecture (with a block size of 8192), as follows:
* It is also a value that divides evenly into the 1 GB storage segments of an
IBM DS8000,
* These 1 GB segments are the allocation unit in the IBM DS8000 and are
equivalent to 1,113 cylinders.

I'm sure the index architecture references the index vtoc architecture, which
has always been a curious archeture to me. Has this design ever been made open? Just
curious as to why it made 21 the magic number?

I also ran into a math issue when I divided 21 into 1GB (or 1,073,741,824/21 =
51,130,563.0476...). I suspect that's because the 1GB storage segment is a
number used in the DS8000 degisn, and its really close to the 1GB value.
Wondering if that's true or some other reason.

Just makes me go hmmm.

Not mentioned above, but IMHO important for MVS: CA size.

The smallest portion of data (known as cluster size in distributed
systems) is CA. VSAM dataset consist of natural number (1,2,3,4,5,..) of
CA's.
Before EAV CA size was any number of tracks within single cylinder - for
3390 it was 1,2,3,4,...15. (fine print: I excluded striping from the
consideration).
Before EAV the allocation was made in tracks, so even the smallest CA
was equal chunk of allocation (or multiplicity).
Now ther is a need to use bigger chunks. What numer to choose? 10 cyl?
100 cyl? 53 cyl? 19 cyl?

What criteria to use?
It would be good the CA size is multiplicity of chunk size, with no
remainder.
21 cyl means 315 trk, it yields quite lot of previous CA sizes: 1,3,7,9,
15. The largest one (15) is the most important here, because it is
suggested CA size.

Of course 210 cyl also allows for the above CA sizes, but the goal is
also to have the chunk size not to large.

--
Radoslaw Skorupka
Lodz, Poland

--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.

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

Re: STC looping and caused the virtaul memory csa shortage

KUMAR Anil wrote:
Recently we had an issue in one LPARs where in a product STC (which starts, 
plants a hook and then ends) was looping. It consumed csa/ecsa and the LPAR 
was affected very much. 

What is the product? Talk with your vendor of that product. How do you know it 
is looping?

We are looking at suggestions /inputs on how to handle these situations. If 
there are any automations put in place to handle such situations (for e.g. a 
particular STC should not start more than 5 times or a HOOK resource's status 
being captured), please provide details.

Automation, for example a SYSLOG scanner, can help you, but will not solve the 
actual problem. Just escalate it with your product vendor.

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

Re: STC looping and caused the virtaul memory csa shortage

What do consider or perceive makes it Looping?  Is it high CPU Utilization,
is it something else?

Any messages in SYSLOG at the time of the even that might provide some
insight?

Any dumps or abends that occurred during this time?

Did you contact the owner of the STC (Providing it is vendor supported and
not home grown)?  

It is hard to provide suggestions not knowing the STC or what the HOOK goes
into.

What automation tools do you have available?  Tivoli Omegamon, CA SYSVIEW,
CA OPS/MVS, other?

How would you normally monitor for this type of condition?  Does someone
just notice something is not quite right?



Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of KUMAR Anil
Sent: Thursday, September 12, 2013 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: STC looping and caused the virtaul memory csa shortage

Hi All,

Recently we had an issue in one LPARs where in a product STC (which starts,
plants a hook and then ends) was looping. It consumed csa/ecsa and the LPAR
was affected very much. 

We are looking at suggestions /inputs on how to handle these situations. If
there are any automations put in place to handle such situations (for e.g. a
particular STC should not start more than 5 times or a HOOK resource's
status being captured), please provide details.

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

Re: PDS/E, Shared Dasd, and COBOL V5

I believe that those who disagree with me and I are arguing at cross
purposes.  Testing is essential, but repetitive atomic testing is
seldom valuable.  In shops where it is the norm production ABENDs and
job reruns occur anyway.

Some shops known to me have long since eliminated non-system PDSs,
replacing them with PDSEs.  I have indeed assisted with this process
on, I find, five occasions.  Others have found arguments, compelling
for them, to avoid PDSEs all but completely.

This is unfortunate but not unexpected.  There have been voices here,
respected ones, assuring us that they have done this conversion
without interesting incident; but they have been largely ignored.

I have made no secret of my view that the management of too many
mainframe shops is compulsively risk-averse, suspiciously unanimous in
its rejection of innovation, in a word, reactionary.

These attitudes are destroying the mainframe, has perhaps already done
so.  I do not really expect my rhetoric to change them, but I shall
continue to make my views clear in concrete situations in which it
seems to me appropriate to do so.

John Gilmore, Ashland, MA 01721 - USA

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

Re: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Frank Swarbrick

I believe Tom Ross explained this, but some might have missed it.  The main 
reason, from what I've heard, is so that the 'debug' data can be stored in a 
no-load segment of the program object.  Thus the debug data will not be 
(automatically) loaded in to memory at execution time, but will be loaded only 
if requested by a tool such as IBM Fault Analyzer or IBM Debug Tool.  This 
eliminates the long standing hassle of keeping the debug data in sync with 
the executable.  And I for one welcome it!

And while I forsee some effort to convert our executable libraries from PDS to 
PDSE, and while we haven't come up with our plan for doing so, I don't see it 
as being as big a hassle here as it will be in other shops.  It will certainly 
take an outage so that the conversion can be run while no applications are 
accessing the libraries, but we have only a few production ones.






 From: Thomas Conley pinnc...@rochester.rr.com
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Thursday, September 12, 2013 9:22 AM
Subject: Re: PDS/E, Shared Dasd, and COBOL V5
 

On 9/12/2013 9:03 AM, Lizette Koehler wrote:
 Tom,

 I might suggest you underestimated the outage time and costs.  For the
 compiler and source management software - probably 2 hours.

 But to change out all of the load libraries into PDS/E datasets - much
 longer.

 That will impact any function in z/OS that runs production code.  So assume
 that joblibs/steplibs in any DB2 Stored procedure, CICS STC DFHREPL, IMS
 STCs DFSRESLB, MQ STCs, and all batch JCL have to change.  That outage could
 a huge impact.

 I do not see the conversion from PDS to PDS/E big if all rules are followed.
 But if I have an application load library that needs to be changed from PDS
 to PDS/E that is in all of the above mentioned JCL, then I have to have
 everything come down on all systems at one time.  That could be a much
 longer window and almost a Plex wide outage.

 Yes, one could start by putting in an empty PDS/E above the PDS in all of
 the above mentioned JCL and then over time get things straightened out.  I
 could not start loading that PDS/E until all the application JCL has also
 had it added.

 Yet, even with a pre-staging of the PDS/E into the JCL.  Our shop, for
 example, has not cycled some of these types of tasks for over 4 months.  Our
 time line to change to PDS/E in these tasks (CICS, IMS, MQ, DB2, etc...)
 would be at least 6 months or so for a normal process.  To cycle these tasks
 sooner could take an act of some deity.

 For the application group much longer to start changing all of their
 steplibs and joblibs.  They have more work, because, even if it is a benign
 change like adding one DD statement to the steplib/joblib - that JCL has to
 go through all the normal checkout processes.  QA, Unit test, Validation,
 change control, etc   That could take up to a year or so; however, if
 you have 60k or so product batch JCL (and you do not know which ones are
 really live), it could take even longer.  Therefore, until all the
 application JCL has been updated, the STCs would continue to have an empty
 PDS/E dataset.  That is where I see the issue.

 So one version of this plan, how change all PDS to PDS/E for load modules,
 would be to start with forcing the Change Management Software to include an
 empty PDS/E into all JCL that goes through it for steplib and joblib.
 System folks would start by placing the same empty PDS/E into the JCL they
 manage.  Lastly the shop's management would need to assign a group of
 application folks to focus on review and changing the remaining JCL for
 production.  It will be almost like a Y2K effort.  There would also need to
 be an analysis of how many PDS/E Datasets will be needed.

 As some applications will have unique PDSs for their applications so tasks
 like the CICS DFHRPL may not have 1 PDS for application load modules but
 MULTIPLE PDS datasets.  And your storage admin folks will also need to be
 involved as some load libraries are huge and there would need to be two of
 everything until the conversions complete - 1 PDS (current) 1 PDS/E - future
 replacement.


 Just my $0.02 worth.

 Lizette


snip
    Let's assume 1000 COBOL licenses in the world, with 100 executable
 datasets per license (IMNSHO, ridiculously conservative estimates).  So
 that's 100,000 executable datasets.  I'll set, again, a conservative
 estimate of $1,000 to convert the PDS to PDSE.  Here is how I break that
 down.  Planning - 1 hour.  Allocating and copying - 1 hour.  Change control
 paperwork - 2 hours.  Implementation - 2 hours.
 Post-implementation followup - 2 hours.  That's 8 hours at a fully-burdened
 rate of $125/hr.  I haven't even figured in the cost of DASD.  That's $100M
 US just to convert this small scenario I've laid out here.

 This is the last time I'll ever respond to a post by John Gilmore.

 Regards,
 Tom Conley


Lizette,

Great analysis of some of the operational costs involved in this PDS to

Re: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Ed Jaffe


On 9/12/2013 8:13 AM, Greg Shirey wrote:

While the process of converting a PDS to a PDSE is indeed trivial, what happens 
after may not be so.  I know my CIO would want assurances that this process 
would not disrupt our business at all.  I might automate the actual conversion, 
but I would spend a whole lot of time testing first and monitoring it 
afterwards.


About ten years ago we added DSNTYPE(LIBRARY) to IGDSMSxx. It's 
amazing how many issues, albeit small ones, that created--even in our 
little shop.


There are a surprising number of PDS usage scenarios that work 
differently (or not at all) with PDSE. I guarantee that some adjustments 
will need to be made. Now and then DSNTYPE=PDS needs to be added to some 
JCL to work around such an issue. Things are a bit tougher with DYNALLOC 
scenarios...


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

Looking for COBOL V5R1 Softcopy Librarian docs

2013-09-12 Thread Charles Mills

I use IBM BookManager on Windows, and IBM Softcopy Librarian. I am looking
for Enterprise COBOL V5R1 docs in either the IBM Publib Boulder or
Internet source and not finding anything. The z/OS bookshelves have not
been updated this year (but VSE and VM were updated as recently as this past
July). What am I missing? Am I the last person in the world using
BookManager on Windows?

Charles 

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

STC looping and caused the virtaul memory csa shortage

2013-09-12 Thread KUMAR Anil

Hi All,

Recently we had an issue in one LPARs where in a product STC (which starts, 
plants a hook and then ends) was looping. It consumed csa/ecsa and the LPAR was 
affected very much. 

We are looking at suggestions /inputs on how to handle these situations. If 
there are any automations put in place to handle such situations (for e.g. a 
particular STC should not start more than 5 times or a HOOK resource's status 
being captured), please provide details.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This email originates from AXA Technology Shared Services, which has its 
registered office at Tower B, 2nd  4th Floor, RMZ Infinity, Old Madras Road, 
Bangalore – 560016, India

This message and any files transmitted with it are confidential and intended 
solely for the individual or entity to whom they are addressed. If you have 
received this in error, you should not disseminate or copy this email. Please 
notify the sender immediately and delete this email from your system. 

Please also note that any opinions presented in this email are solely those of 
the author and do not necessarily represent those of AXA Technology Shared 
Services Group. 

Email transmission cannot be guaranteed to be secure, or error free as 
information could be intercepted, corrupted, lost, destroyed, late in arriving 
or incomplete as a result of the transmission process. The sender therefore 
does not accept liability for any errors or omissions in the contents of this 
message which arise as a result of email transmission. 

Finally, the recipient should check this email and any attachments for viruses. 
AXA Technology Shared Services accepts no liability for any damage caused by 
any virus transmitted by this email.

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

Re: PDS/E, Shared Dasd, and COBOL V5

In 5231e3f7.9090...@phoenixsoftware.com, on 09/12/2013
   at 08:55 AM, Ed Jaffe edja...@phoenixsoftware.com said:

There are a surprising number of PDS usage scenarios that work 
differently (or not at all) with PDSE.

Sure. But wouldn't it have been prudent for shops to start slowly
migrating after PDSE had aged a bit, say a decade? Why create a crisis
by waiting until the last minute?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Looking for COBOL V5R1 Softcopy Librarian docs

Lizette Koehler wrote:

No more BOO books I think.  Only PDF

Older versions like 4.2 and earlier have 2 types: BOO and PDF.

http://www-01.ibm.com/support/docview.wss?uid=swg27036733

That is one mother of a COBOL link with links to 7 versions of Enterprise COBOL 
and other nice resources!

Ok, however there are no nice search facilities across bookshelves, but never 
mind.

Thanks Lizette! ;-D

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

Re: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Paul Peplinski

I was concerned when I saw the PDS/E requirement for COBOL 5 load modules, not 
only because of the effort involved but also because of some prior PDS/E 
problems - some fairly recent and some not so recent.

I discovered to my surprise that our application load libraries have been PDS/E 
for years.

Paul

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

Re: Currently dispatched TCB in SRB mode

In dff339povt538g7a6bi2gc5p150rf91...@4ax.com, on 09/12/2013
   at 04:14 PM, Binyamin Dissen bdis...@dissensoftware.com said:

As the data is available to other processors, it was obvious to me
that changes could not be made unilaterally.

What was not obvious was how just disabling interrupts was enough to
serialize the data. Jim's reference to Bind Break clarified that.

IBM has carefully worked out serialization rules for its own code; if
the customer messes with protected data, it's the customer's
responsibility to understand and follow the rules. I'd hardly call it
unilateral if IBM code changes something after properly serializing
it.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: NTP server with System z for PCI-DSS compliance

In 5231cab7.8000...@acm.org, on 09/12/2013
   at 09:07 AM, Joel C. Ewing jcew...@acm.org said:

Forward-only nudging wouldn't be very useful unless the TOD clock was
also deliberately designed to always run a hair slow

Then maybe steering by slowing down every N ticks, but I'd be very
nervous about anything that actoually set the TOD back.

if you allow z/OS time to jump discontinuously

Isn't clock steering now part of the z base?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

SORT Help

2013-09-12 Thread Ron Thomas

Hello

We have a input file defintion as PIC S9(4)V9(5) COMP-3   we are modifying the 
same to PIC S9(5)V9(5) COMP-3. The file is created with this new data 
definition.

This modified file is fed to a third party application where we are moving the 
data to teradata and here the data is defined as DECIMAL(9,5).  The file is 80 
bytes in length and this fields starts in position 10.  We are thinking of 
putting a SORT step to do the transformation so that data goes in the way it 
used to be.

Once the teradata table is modifled at some point of time we will remove the 
step. Pls some one let me know how SORT to be applied so that data truncations 
will not come?

Thanks
Ron T

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

Re: SORT Help

2013-09-12 Thread Sri h Kolusu

Ron,

I am not really sure you even need a sort step to load into Tera data.  I 
am not familiar with teradata load cards , but if it behaves anything like 
DB2, and your intention is to load only 5 bytes you can specify the start 
position to 11 (instead of 10) on your load card to load only the 5 bytes. 
Check out the examples here which shows how you can specify the positions 
of the data to be loaded.

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DSNUGJ12/2.14.6

If you insist on using a sort step to copy then you can use the following.

//STEP0100 EXEC PGM=SORT 
//SYSOUT   DD SYSOUT=* 
//SORTIN   DD DISP=SHR,DSN=Your input FB 80 byte file
//SORTOUT  DD SYSOUT=* 
//SYSINDD * 
  OPTION COPY 
  OUTREC BUILD=(1,9,11,70,X) 
//* 

We will have a space at the end to account for the additional byte we 
dropped off.

Kolusu
DFSORT Development

IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 
09/12/2013 10:39:43 AM:

 From: Ron Thomas ron5...@gmail.com
 To: IBM-MAIN@listserv.ua.edu, 
 Date: 09/12/2013 10:40 AM
 Subject: SORT Help
 Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu
 
 Hello
 
 We have a input file defintion as PIC S9(4)V9(5) COMP-3   we are 
 modifying the same to PIC S9(5)V9(5) COMP-3. The file is created 
 with this new data definition.
 
 This modified file is fed to a third party application where we are 
 moving the data to teradata and here the data is defined as DECIMAL
 (9,5).  The file is 80 bytes in length and this fields starts in 
 position 10.  We are thinking of putting a SORT step to do the 
 transformation so that data goes in the way it used to be.
 
 Once the teradata table is modifled at some point of time we will 
 remove the step. Pls some one let me know how SORT to be applied so 
 that data truncations will not come?
 
 Thanks
 Ron T
 
 --
 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: PDS/E, Shared Dasd, and COBOL V5

Among the usage scenarios Ed Jaffe presumably alludes to in

begin extract
There are a surprising number of PDS usage scenarios that work
differently (or not at all) with PDSE.
end extract/

is required routine, periodic compression, which is not needed.  There
are, of course, major differences; and there should be; PDSs are
inadequate in a great many ways that were once well understood.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Looking for COBOL V5R1 Softcopy Librarian docs

Only thing I can find is this  Windows 4.0.  These are both from 2012



http://www-01.ibm.com/support/docview.wss?uid=swg24001220

IBM Softcopy Reader for Windows V4.0



http://www-01.ibm.com/support/docview.wss?uid=swg24000640

IBM Softcopy Librarian V4.6


Since I use Mozilla with DOWNTHEMALL - I have no problem bringing down the
PDF files enmass

Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, September 12, 2013 10:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for COBOL V5R1 Softcopy Librarian docs

Sorry. I was not clear. (My excuse is I am sitting in an airport on weather
hold.) I don't mean the IBM proprietary book *format.* Yeah, I like the
search on those but that's a different topic. PDF is fine.

The program I use to read the docs is IBM Softcopy Reader 3.8. I like the
way it organizes the books in shelves (including the PDFs).

The program I use to download docs is called (IBM) SoftCopy Librarian 4.
It retrieves books from the Internet (?) or IBM Publib Boulder. I like
that it works with the Bookshelf organization. THAT is the program in
which the IBM repositories show as a year back-dated. THAT is the problem I
am trying to solve.

Okay, am I clearer now? Thanks, and apologies.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Thursday, September 12, 2013 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for COBOL V5R1 Softcopy Librarian docs

No more BOO books I think.  Only PDF

http://www-01.ibm.com/support/docview.wss?uid=swg27036733



Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, September 12, 2013 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Looking for COBOL V5R1 Softcopy Librarian docs

I use IBM BookManager on Windows, and IBM Softcopy Librarian. I am looking
for Enterprise COBOL V5R1 docs in either the IBM Publib Boulder or
Internet source and not finding anything. The z/OS bookshelves have not
been updated this year (but VSE and VM were updated as recently as this past
July). What am I missing? Am I the last person in the world using
BookManager on Windows?

Charles 

--
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: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Gerhard Postpischil


On 9/12/2013 12:25 PM, Frank Swarbrick wrote:

I believe Tom Ross explained this, but some might have missed it.
The main reason, from what I've heard, is so that the 'debug' data
can be stored in a no-load segment of the program object.  Thus the
debug data will not be (automatically) loaded in to memory at
execution time, but will be loaded only if requested by a tool such
as IBM Fault Analyzer or IBM Debug Tool.  This eliminates the long
standing hassle of keeping the debug data in sync with the
executable.  And I for one welcome it!


Ever since Assembler F (OS/360), debug data in the form of SYM records 
has been available, in complete synchronization with the executable. It 
would not have taken much work to extend this to CoBOL to provide 
additional data, similar to the data available with the HL ADATA option.


So this may be a benefit of the PDS/E requirement, but hardly a necessity.

Gerhard Postpischil
Bradford, Vermont

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

Re: Teletypewriter Model 33

2013-09-12 Thread Anne Lynn Wheeler

Robert Wessel robertwess...@yahoo.com writes:
The managed to reintroduce type-ahead on 3174s with the Entry
Assists feature. A major change in the 3174s was a much faster CPU
than in the 3274s, and a vast increase in memory, so there was room to
add those features. The terminal itself, nor the protocol on the
wire, were not really the problem, mainly that the 3274 was
underpowered for handling much of that work the dumber 3278 push back
to the controller.

but by the time of the 3174 ... 3270s were moving to dumb terminal
emulation and type-ahead was being handled in emulators.
http://en.wikipedia.org/wiki/IBM_3270

Note that by the time of the 3277 emulation card upload/download being
3times throughput of 3278 emulation card upload/download ... were on same
3274 controllers (i.e. datacenters were upgrading all controllers to 3274
... but some configured to handle 3277 protocol). ... 3277 attached to
3274 ... section 7-37, 7-38
http://www.bitsavers.org/pdf/ibm/3270/GA27-2749-10_3270_Information_Display_System_Component_Description_Feb80.pdf

the 3174 faster processor would have helped ... but didn't eliminate the
difference in 3277 coax protocol chatter versus 3278 coax protocol
chatter.

a senior disk engineer managed to get a talk scheduled at the annual,
internal communication group conference ... supposedly on the subject of
3174 performance ... but opened the talk with the statement that the
communication group was going to be responsible for the demise of the
disk division.

the issue was the communication group was desperately trying to fight
off client/server and distributed computing and protect their dumb
(emulated) terminal install base. the disk division was seeing a drop in
disk sales with data fleeing the datacenters to more distributed
computing friendly platforms. the disk division had come up with a
number of solutions to address the opportunities ... but they were
constantly being vetoed by the communication group ... which had
corporate strategic responsibility for everything that crossed the
datacenter walls

note that 2-3yrs earlier, the top executives had predicted that the
company revenue was going to double ... mostly based on mainframes ...
and instituted massive building program to double mainframe
manufacturing capacity (even tho indicators were already that it was
starting to head in the opposite direction) ... company going into the
red in the early 90s and big decline in mainframe business.

also note these kind of battles with communication group go back even
further. my wife had been con'ed into going to POK to be in charge of
mainframe loosely-coupled architecture ... where she did peer-coupled
shared data architecture ... some past posts
http://www.garlic.com/~lynn/submain.html#shareddata

... which saw little uptake until sysplex ... except for IMS
hot-standby. The lack of uptake contributed to her not staying long ...
however also there were the re-occuring battles with the communication
group trying to force her into using SNA for loosely-coupled operation.
There would be periodic termporary truces where they said she could use
anything she wanted within the datacenter, but the communication group
owned everything that crossed the datacenter walls ... but they would
then resume their efforts to try and force her to use SNA.

--
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Farley, Peter x23353

It seems to me that the first reason for the PDSE requirement was their choice 
to use the Java backend code generator, which always generates GOFF instead of 
classic object decks, instead of, for instance, the C/C++ backend which can 
generate simple object decks (so long as only simple pre-GOFF facilities are 
used), and that the second reason was their decision to use DWARF format for 
the no-load debugging and other non-executing runtime information that requires 
program-object-only formats in the binder output executable.

I agree that understanding the path of that decision process leads to many 
questions.  I fervently wish I had been able to participate actively in SHARE 
over the last few years to help guide such a decision path in different 
directions (assuming, of course, that the decision makers even cared what SHARE 
participants' opinions are/were).

I do not blame Tom Ross.  He is only the messenger, and I would not wish to see 
him shot for the difficulties that will be brought on us by the message.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Thomas Conley
Sent: Thursday, September 12, 2013 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PDS/E, Shared Dasd, and COBOL V5
Snipped

Lizette,

Great analysis of some of the operational costs involved in this PDS to 
PDSE conversion just to support COBOL V5.1.  In many shops, this will 
not be a trivial exercise, as some on IBM-Main have stated.  This will 
be a serious migration effort, and cost significant dollars.  I'm still 
mystified as to why IBM felt it had to impose this completely 
unnecessary restriction.  What reason is there to force COBOL V5.1 
executables to come from a PDSE?

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: ACS routine trace.

2013-09-12 Thread Darth Keller

Sorry, long day - I forgot you said this was a dynamic allocation, which 
is what made me thing about going back to NaviQuest in the 1st place.

my bad -
ddk



/

But that's the beauty of NaviQuest - you can set up your test case, test 
it against your 'live' code changing values until your results match what 
you're seeing.  Then you can run that test case against new code to see 
what it does with the data.

As to not knowing what is being presented to the routines,  you can add 
variables to your WRITE statement to tell you exactly what SMS sees. 

In the case I was working on yesterday, my test dataset was falling out of 

the code a long way from where I thought it was supposed to  I couldn't 
see why.   So I updated to WRITE statement where it was falling out of the 

code and added a dozen different variables to the WRITE - specifically I 
wanted to see the variable I was testing for in the earlier segment.   I 
was testing for the RACF defaults security is supposed to set up when they 

define a new user ID - my displays showed me that for this ID that had not 

happened.   There was actually nothing wrong with the code - it was in how 

the ID was set up -

I've been doing this a lot of years and haven't found an instance yet that 

I couldn't debug using WRITE statements and the right combinations of 
WRITE Variables.

HTH's.
ddk

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

Re: How to display JES2 fields from the PDDB

2013-09-12 Thread Hansen, Dave L - Eagan, MN

Joe,

   Thank you for the tips on slip traces.  We still are trying to figure out 
the PDBDNODE change consequences.   Sorry for the blank post earlier.


  Thanks again,  Dave



-Original Message-
From: Hansen, Dave L - Eagan, MN 
Sent: Thursday, September 12, 2013 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RE: How to display JES2 fields from the PDDB



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe D'Alessandro
Sent: Wednesday, September 11, 2013 11:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to display JES2 fields from the PDDB

Hello:
You may be better served by using an IF SLIP and writing trace records 
(A=TRACE) to a GTF that specifies TRACE=SLIP so that you can get a greater 
variety of PDDB iterations.   A dump is going to just get you one PDDB  at that 
point in time.

Use $DMOD(modname) to get the address of the exit’s load point.  Use that 
address to build the SLIP.  Here is an example of a SLIP one of my co-workers 
wrote in the past:

SLIP SET,IF,DISABLE,ID=TRCJ,ACTION=TRACE,J=JES2,
 RA=(1A9DE4F8+01F0,1A9DE4F8+0FC6),
 TD=(STD,REGS),
 END

It looks legit to me.  I never did an IF trace for a JES2 exit, but I have used 
IF for other traces and in those cases I  actually coded a module name.   

The RANGE you code would be the address in your exit where you knew the PDDB’s 
address was loaded into reg2.  You might just place the IF on one instruction 
(in the above example, he was tracing code path thru some module).  

And you would add to the TRDATA parameter that the locations pointed to by reg2 
should be written to the trace record, e.g.,  TD=(STD,REGS,2r?+14,2r?+20) 

Which means “dump the standard trace record and the register values and what 
reg2 is pointing to plus x’14’ thru x’20’.

After you set the SLIP (and warn everyone first that you are setting a PER 
trap), start the GTF to capture the trace records.  Then submit jobs to create 
PDDBs.

For what it's worth, my observation of a PDDB found this combination of values 
(JES2 v1.11):   PDBDRMT is interpreted as a U value or a Rnnn value 
depending on PDBDNODE.  I was only checking for certain values of PDBDNODE so I 
came up with this partial set of field contents: 

PDBDNODE   PDBDRMT   PDBDUSER 
  zero   ¬zero  spacesPDBDRMT is a U value 
 our-node ¬zero  spacesPDBDRMT is Rnnn value.
 our-node  zero   U PDBDUSER contains the actual U 
value
 our-node  zero   spaceslocal SYSOUT

I did not care if PDBDNODE contained another node's value so I am not going to 
state what would be in PDBDRMT or PDBDUSER in that case, but the SLIP / TRACE 
should find that if you need to know.

regards, Joe D'Alessandro

--
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: How to display JES2 fields from the PDDB

2013-09-12 Thread Hansen, Dave L - Eagan, MN

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe D'Alessandro
Sent: Wednesday, September 11, 2013 11:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to display JES2 fields from the PDDB

Hello:
You may be better served by using an IF SLIP and writing trace records 
(A=TRACE) to a GTF that specifies TRACE=SLIP so that you can get a greater 
variety of PDDB iterations.   A dump is going to just get you one PDDB  at that 
point in time.

Use $DMOD(modname) to get the address of the exit’s load point.  Use that 
address to build the SLIP.  Here is an example of a SLIP one of my co-workers 
wrote in the past:

SLIP SET,IF,DISABLE,ID=TRCJ,ACTION=TRACE,J=JES2,
 RA=(1A9DE4F8+01F0,1A9DE4F8+0FC6),
 TD=(STD,REGS),
 END

It looks legit to me.  I never did an IF trace for a JES2 exit, but I have used 
IF for other traces and in those cases I  actually coded a module name.   

The RANGE you code would be the address in your exit where you knew the PDDB’s 
address was loaded into reg2.  You might just place the IF on one instruction 
(in the above example, he was tracing code path thru some module).  

And you would add to the TRDATA parameter that the locations pointed to by reg2 
should be written to the trace record, e.g.,  TD=(STD,REGS,2r?+14,2r?+20) 

Which means “dump the standard trace record and the register values and what 
reg2 is pointing to plus x’14’ thru x’20’.

After you set the SLIP (and warn everyone first that you are setting a PER 
trap), start the GTF to capture the trace records.  Then submit jobs to create 
PDDBs.

For what it's worth, my observation of a PDDB found this combination of values 
(JES2 v1.11):   PDBDRMT is interpreted as a U value or a Rnnn value 
depending on PDBDNODE.  I was only checking for certain values of PDBDNODE so I 
came up with this partial set of field contents: 

PDBDNODE   PDBDRMT   PDBDUSER 
  zero   ¬zero  spacesPDBDRMT is a U value 
 our-node ¬zero  spacesPDBDRMT is Rnnn value.
 our-node  zero   U PDBDUSER contains the actual U 
value
 our-node  zero   spaceslocal SYSOUT

I did not care if PDBDNODE contained another node's value so I am not going to 
state what would be in PDBDRMT or PDBDUSER in that case, but the SLIP / TRACE 
should find that if you need to know.

regards, Joe D'Alessandro

--
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: ACS routine trace.

2013-09-12 Thread efinnell15

Can you turn on verbose logging for the specific APP during the event in 
question? Maybe something irregular would solve the mystery. I would guess 
something like a temp creation and a rename.



In a message dated 09/12/13 14:46:28 Central Daylight Time, 
kees.verno...@klm.com writes:
I can only debug this problem in a live envirionment, hence the 'tracing' 
needed for the live ACS routines. 

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

Re: STC looping and caused the virtaul memory csa shortage

2013-09-12 Thread Mark Zelden

On Thu, 12 Sep 2013 15:45:54 +, KUMAR Anil anil.kum...@axa-tss.com wrote:

Hi All,

Recently we had an issue in one LPARs where in a product STC (which starts, 
plants a hook and then ends) was looping. It consumed csa/ecsa and the LPAR 
was affected very much. 

We are looking at suggestions /inputs on how to handle these situations. If 
there are any automations put in place to handle such situations (for e.g. a 
particular STC should not start more than 5 times or a HOOK resource's status 
being captured), please provide details.


Some suggestions:

1) System Health Checker. Depending on how gradual or fast the (E)CSA 
exhaustion took place,
this most likely would have given you plenty of time to react.   The automation 
would be based on
messages HC issues and could do something like page / email someone or could 
cancel an offending
task etc. 

2) Any other threshold monitor (Omegamon, TMON, Sysview, Mainview, etc).
Health Checker
however has the right price if you don't have one of those (free!).

3) PFA (Predictive Failure Analysis).   A good tool also, but probably less 
help for a runaway situation like
this.   For gradual growth it is more helpful and it also understands that at 2 
pm peak your CSA usage is
expected to be higher than at 5 a.m. before you start all your CICS regions 
(just an example).

As far as the loop itself, you know blank happens and the best thing to do is 
be prepared and have tools
in place to monitor your system for abnormalities, have a robust paging system 
etc. YMMV

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS  
mailto:m...@mzelden.com 
ITIL v3 Foundation Certified 
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Currently dispatched TCB in SRB mode

In 5231f289.9080...@phoenixsoftware.com, on 09/12/2013
   at 09:57 AM, Ed Jaffe edja...@phoenixsoftware.com said:

And that serialization is often *NOT* documented! You have to learn
it via (in-person or electronic) discussions with helpful folks like
Jim Mulder

Who was very helpful.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: ACS routine trace.

2013-09-12 Thread Darth Keller

But that's the beauty of NaviQuest - you can set up your test case, test 
it against your 'live' code changing values until your results match what 
you're seeing.  Then you can run that test case against new code to see 
what it does with the data.

As to not knowing what is being presented to the routines,  you can add 
variables to your WRITE statement to tell you exactly what SMS sees. 

In the case I was working on yesterday, my test dataset was falling out of 
the code a long way from where I thought it was supposed to  I couldn't 
see why.   So I updated to WRITE statement where it was falling out of the 
code and added a dozen different variables to the WRITE - specifically I 
wanted to see the variable I was testing for in the earlier segment.   I 
was testing for the RACF defaults security is supposed to set up when they 
define a new user ID - my displays showed me that for this ID that had not 
happened.   There was actually nothing wrong with the code - it was in how 
the ID was set up -

I've been doing this a lot of years and haven't found an instance yet that 
I couldn't debug using WRITE statements and the right combinations of 
WRITE Variables.

HTH's.
ddk

///
No, I didn't. But I don't think this will help here, because I don't know 
what is being presented to the ACS routines and the problem occurs only on 
a specific allocation of a specific product with one specific data set. I 
can only debug this problem in a live environment, hence the 'tracing' 
needed for the live ACS routines.
 
Kees.



Van: IBM Mainframe Discussion List namens Darth Keller
Verzonden: do 12-9-2013 17:21
Aan: IBM-MAIN@LISTSERV.UA.EDU
Onderwerp: Re: ACS routine trace.



I'm curious.  Do you ever use the NaviQuest SMS test facility?
ddk

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

Re: Looking for COBOL V5R1 Softcopy Librarian docs

No more BOO books I think.  Only PDF

http://www-01.ibm.com/support/docview.wss?uid=swg27036733



Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, September 12, 2013 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Looking for COBOL V5R1 Softcopy Librarian docs

I use IBM BookManager on Windows, and IBM Softcopy Librarian. I am looking
for Enterprise COBOL V5R1 docs in either the IBM Publib Boulder or
Internet source and not finding anything. The z/OS bookshelves have not
been updated this year (but VSE and VM were updated as recently as this past
July). What am I missing? Am I the last person in the world using
BookManager on Windows?

Charles 

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

Re: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Wayne Driscoll

Gerhard,
Isn't SYM data limited to 8 character labels, which is why ADATA, which is
in a different file, not in the object deck, so subject to the same
syncronization data that GOFF will protect against?

==
Wayne Driscoll
OMEGAMON DB2 L3 Support/Development
wdrisco(at)us(dot)ibm(dot)com
All opinions are mine, and do not represent
IBM Corporation.
==
IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on
09/12/2013 01:47:42 PM:

 From: Gerhard Postpischil gerh...@valley.net
 To: IBM-MAIN@listserv.ua.edu,
 Date: 09/12/2013 01:48 PM
 Subject: Re: [IBM-MAIN] PDS/E, Shared Dasd, and COBOL V5
 Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu

 On 9/12/2013 12:25 PM, Frank Swarbrick wrote:
  I believe Tom Ross explained this, but some might have missed it.
  The main reason, from what I've heard, is so that the 'debug' data
  can be stored in a no-load segment of the program object.  Thus the
  debug data will not be (automatically) loaded in to memory at
  execution time, but will be loaded only if requested by a tool such
  as IBM Fault Analyzer or IBM Debug Tool.  This eliminates the long
  standing hassle of keeping the debug data in sync with the
  executable.  And I for one welcome it!

 Ever since Assembler F (OS/360), debug data in the form of SYM records
 has been available, in complete synchronization with the executable. It
 would not have taken much work to extend this to CoBOL to provide
 additional data, similar to the data available with the HL ADATA option.

 So this may be a benefit of the PDS/E requirement, but hardly a
necessity.

 Gerhard Postpischil
 Bradford, Vermont

 --
 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: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Clark Morris

On 11 Sep 2013 13:59:52 -0700, in bit.listserv.ibm-main you wrote:

I had begun to think that my experience with PDSEs was somehow
atypical, too lucky, because I had not encountered the grievous
problems that featured in others' war stories.

I therefore spent a long afternoon trying to reproduce and clear some
of these problems.  My experience was much like Mark's.  The problems
reported here did---some of them anyway---occur; but they were readily
cleared away.

I conclude that this is a problem of a different sort.   Some people
will continue to use PDSs, 3270 emulators, and the like until they are
pried, irrelevantly, from their cold dead hands.

They are and should be free to do this, but it  needs to be understood
that no technical argument will avail against their rooted
preferences.

While I have been away from systems programming for over a decade, I
am appalled to see that a PDSE still cannot contain SYS1.LINKLIB,
SYS1.LPALIB and SYS1.NUCLEUS.  Whoever came up with the idea that a
major access method should be done by a started task should be
consigned to the same hell as the person who decided that local SNA
327X devices could only be accessed though VTAM thus requiring shops
to have 2 BiSync 327x controllers for console availability.  Would
anyone care if NIP took a cylinder, 2 cylinders or even 100 cylinders.
If started task is a good idea for PDSE, it should be equally good for
VSAM.  At least code to read PDSE's should be available to NIP and
maybe SYS1.NUCLEUS.  

Clark Morris

John Gilmore, Ashland, MA 01721 - USA

--
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 COBOL V5R1 Softcopy Librarian docs

2013-09-12 Thread Charles Mills

Sorry. I was not clear. (My excuse is I am sitting in an airport on weather
hold.) I don't mean the IBM proprietary book *format.* Yeah, I like the
search on those but that's a different topic. PDF is fine.

The program I use to read the docs is IBM Softcopy Reader 3.8. I like the
way it organizes the books in shelves (including the PDFs).

The program I use to download docs is called (IBM) SoftCopy Librarian 4.
It retrieves books from the Internet (?) or IBM Publib Boulder. I like
that it works with the Bookshelf organization. THAT is the program in
which the IBM repositories show as a year back-dated. THAT is the problem I
am trying to solve.

Okay, am I clearer now? Thanks, and apologies.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Thursday, September 12, 2013 12:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for COBOL V5R1 Softcopy Librarian docs

No more BOO books I think.  Only PDF

http://www-01.ibm.com/support/docview.wss?uid=swg27036733



Lizette


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, September 12, 2013 9:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Looking for COBOL V5R1 Softcopy Librarian docs

I use IBM BookManager on Windows, and IBM Softcopy Librarian. I am looking
for Enterprise COBOL V5R1 docs in either the IBM Publib Boulder or
Internet source and not finding anything. The z/OS bookshelves have not
been updated this year (but VSE and VM were updated as recently as this past
July). What am I missing? Am I the last person in the world using
BookManager on Windows?

Charles 

--
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: Teletypewriter Model 33

In 08df7293-a3ba-47ce-80a6-25eb8a987...@aim.com, on 09/12/2013
   at 08:14 AM, Paul Gilmartin paulgboul...@aim.com said:

That meets my understanding of suggest.

The problem is that I suggested something totally unrelated to what
you attributed to me. I suggest that you try EDIT in order to see how
TSO handles mixed case, since that was the issue in dispute.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: PDS/E, Shared Dasd, and COBOL V5

2013-09-12 Thread Gibney, Dave

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Jim Mulder
 Sent: Thursday, September 12, 2013 1:13 AM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: PDS/E, Shared Dasd, and COBOL V5

  I cracked open a (metaphorical) history book, and I discovered that
  IBM introduced PDSEs in 1989 -- about 24 years ago as I write this.

  I agree with John Gilmore. A 2013 PDSE prerequisite for Enterprise
  COBOL
  5.1 is not too soon.

  Some customers have already stated in this discussion that they have
 program library PDS data sets which they share across sysplex boundaries.
 Unless such a data set is never updated from one sysplex without re-IPLing all
 of the systems in other sysplexes which might access that data set (or at 
 least
 restarting the PDSE1 address space, if you use that), then you cannot convert
 these PDS data sets to PDSEs without exposing yourself to PDSE issues which
 do not occur in the same way for PDS data sets.
 This is due to caching which is done at a system level for PDSE, but not PDS.
 PDSE also does space reclamation differently from PDS, and some customers
 may have operational procedures which depend on the PDS property that
 space is not reclaimed until an explicit compress operation is executed.

Is there any thought of a command or procedure to  refresh the PDS/E system 
level cache? Perhaps with caveats similar to LLA,REFRESH and ACTIVATE?

   So in some cases, a PDSE is not a plug compatible replacement for a PDS.

   What is your proposed solution for customers who currently share COBOL
 PDS libraries across sysplex boundaries?

 You can also get acquainted with PDSEs
  and their impacts. (Did I actually just write that? :-))

   You did indeed write that, and it would suggest that you may be less
 acquainted with some of the impacts of PDSEs than the experienced z/OS
 systems programmers on IBM-MAIN.

   PDSE certainly does have significant advantages over PDS in many
 environments, but there do remain some situations in which the lack of
 caching and the more primitive space reclamation characteristics of PDS can
 be advantageous.

  And while it is certainly reasonable for COBOL to exploit program object
 functionality which is not available with load modules,  the fact remains that
 MVS made a decision long ago to tie program objects to PDSE, and thus for
 some customer environments, moving to COBOL 5.1 may involve operational
 changes which are more complex than simply converting COBOL program
 libraries from PDS to PDSE.

 Jim Mulder   z/OS System 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

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

Re: STC looping and caused the virtaul memory csa shortage

2013-09-12 Thread Shane Ginnane

On Thu, 12 Sep 2013 15:38:08 -0500, Mark Zelden wrote:


Some suggestions:

1) System Health Checker.

2) Any other threshold monitor (Omegamon, TMON, Sysview, Mainview, etc).
Health Checker
however has the right price if you don't have one of those (free!).

3) PFA (Predictive Failure Analysis).

C'mon Mark, don't be so modest- running a script to pull the numbers from the 
GDA like your IPLINFO exec does would also be a well-priced alternative ...   
;-)

Having also had an outage for critical SQA (ESQA in this case) shortage in the 
past week, I can sympathise with the OP. ESQA spilled to ECSA, machine stopped 
responding to any carbon-based lifeform. GRS apparently kept kicking the RSA 
around the ring, and jobs on the queue initiated, but eventually it had to be 
bounced.
No, I don't have a stand-alone dump, but I did meander through an 878-8 which 
is of course a little late in proceedings. However it did show all the action 
was in ASID 0001 - so I'm thinking recovery routines or long lived scheduled 
(vendor ??? - don't get me started again ...) tasks misbehaving. Too many 
broken/unavailable control blocks to be sure.

As for Marks suggestions:
HC - didn't hear of any alerts, but will check when I get back to looking at 
the logs
Monitors - again nothing mentioned. Note to self; check why not.
PFA - useless as a lifeboat on a camel on small systems without operlog.

The age-old question of how you recognise loops as mentioned earlier still 
stands - but shared storage can be tested against high-water marks. I'm 
currently looking to get Omegamon to issue SNMP alerts for things like this, 
but it's more convoluted than it should be.

Shane ...

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

Re: Looking for COBOL V5R1 Softcopy Librarian docs

2013-09-12 Thread Bob Shannon

The COBOL manuals can be found here: 
http://www-01.ibm.com/support/docview.wss?uid=swg27036733

As far as updates to the z/OS library, zVSE and zVM have had new releases more 
recently than z/OS. That may explain why there are no z/OS  updates.  Lizette 
is correct that z/OS 2.1 is PDF-only so say goodbye to Softcopy Reader.

Bob Shannon
Rocket Software

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

Re: NTP server with System z for PCI-DSS compliance

In
of919a62a3.59be1d57-on88257be4.00500ef8-88257be4.00510...@sce.com,
on 09/12/2013
   at 07:44 AM, Skip Robinson jo.skip.robin...@sce.com said:

While the most obvious value of STP may be synchronization of
multiple z  CECs in a glass house, it is invaluable for synchronizing
all z CECs with the rest of the enterprise.

Were IBM to provide an NTP client for single CEC shops, why would it
not fulfill the need to synchronize with the rest of the enterprise?
Or are you talking about multiple z sites in the same enterprise? Even
there STP seems like overkill unless at least one site is multi-CEC.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2http://patriot.net/~shmuel
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Currently dispatched TCB in SRB mode

2013-09-12 Thread Ed Jaffe


On 9/12/2013 9:43 AM, Shmuel Metz (Seymour J.) wrote:

What was not obvious was how just disabling interrupts was enough to
serialize the data. Jim's reference to Bind Break clarified that.

IBM has carefully worked out serialization rules for its own code;


And that serialization is often *NOT* documented! You have to learn it 
via (in-person or electronic) discussions with helpful folks like Jim 
Mulder and Peter Relson--without whom much of the world's z/OS software 
would not reliably work.


--
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: COBOL problem (not really), but sort of.

2013-09-12 Thread Clark Morris

On 11 Sep 2013 10:21:17 -0700, in bit.listserv.ibm-main you wrote:

I can try that. The programmer says that he intents to define the passed in
area in the calling program at the front of his WORKING-STORAGE so that the
area is larger. I.e. it is _planning_ on a buffer overflow and _hoping_
that it doesn't affect the calling program. I don't have authority to
disallow this. And we don't do any kind of peer review because we just
don't have the people left.

In the sub-routine change the READ ... INTO to a READ followed by a
MOVE of the record just read and some value if AT END is reached.

Clark Morris

On Wed, Sep 11, 2013 at 12:09 PM, Thomas Berg thomas.b...@swedbank.sewrote:

 I would say: the READ .. INTO .. statement doesn't look at the numerical
 value in the length field, it only looks at the max possible length as
 defined. And acts accordingly.



 Best Regards
 Thomas Berg
 ___
 Thomas Berg   Specialist   zOS\RQM\IT Delivery   SWEDBANK AB (Publ)

  -Original Message-
  From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
  Behalf Of John McKown
  Sent: Wednesday, September 11, 2013 7:02 PM
  To: IBM-MAIN@LISTSERV.UA.EDU
  Subject: COBOL problem (not really), but sort of.
 
  A programmer came by today with a problem. He is sometimes getting a
  S0C4-4 abend in a COBOL program. This is a subroutine. One of the
  parameters passed in is a data area, which can be of various lengths. It
  is defined with an OCCURS DEPENDING ON with a data element within the
  area. I.e. the first 05 level is PIC S9(5) COMP. The subroutine does a
  READ of a data set into this area. This is where the abend occurs. The
  reason is because the OCCURS DEPENDING ON maximum size is significantly
  larger than what the caller is passing it. And the READ to the 01 is
  trying to pad the entire possible 01 level with blanks.
 
  The problem is how do I describe this to a COBOL programmer who just
  doesn't get it. He expects COBOL to _not_ pad the non existent
  occurrences with blanks. And, if fact, to not even reference this area
  wherein they would have resided, had they existed. I'm just get deer in
  headlights looks. I'm not using the correct words, somehow.
 
  --
  As of next week, passwords will be entered in Morse code.
 
  Maranatha! 
  John McKown
 
  --
  For IBM-MAIN subscribe / signoff / archive access instructions, send
  email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


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

Re: Looking for COBOL V5R1 Softcopy Librarian docs