Re: Change tape block size

[Victor Zhang]

Hello,
First I need thank you who replied to my question.
I should introduce my problem's background and my concern.
The tape is virutal tape of oralce, vsm5.
I am backing up extended format PS dataset to VSM5 using ADRDSSU.
I tested using dss to backup, no matter what block size I specified in JCL, 
ADRDSSU will report same number of blocks in message IEC205I.
And the backup speed will also be same no matter what block size I specified in 
JCL.
Here is my testing result:
st_TIME end_TIMEbackup source data type VOLSER  VTV size(mb)VTV 
size(comp)(mb)  tape block size(KB) Total block count reported by DSS   
backup speed(MB/S)
11:31:4111:33:12Extended format compressed  AB3968  1854.15 
647.77  128 33879   20.38 
11:33:1211:34:42Extended format compressed  AB3974  1854.15 
647.77  64  33879   20.60 
11:34:4211:36:17Extended format compressed  AB3976  1854.15 
647.77  256 33879   19.52 

But this is not true for BASIC PS dataset, for basic PS dataset,  I did a 
similar testing:
st_TIME end_TIMEbackup source data type VOLSER  VTV size(mb)VTV 
size(comp)(mb)  tape block size(KB) Total block count reported by DSS   
backup speed(MB/S)
13:08:0713:11:37Basic PSAB4075  6273.86 360.15  128 
49117   29.88 
13:11:3713:16:00Basic PSAB4078  6274.57 367.9   64  
98426   23.86 
13:16:0013:19:04Basic PSAB4082  6273.51 355.52  256 
24528   34.10 

Please note the total block count reported by DSS is different when specifying 
different tape block size.

My goal was:
To improve backup performance for extended format PS dataset(DB2 image copy on 
dasd)using ADRDSSU,I am trying to use 256KB to improve performace,but I can't.
Do you have any ideas?


Regards
Victor

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

Re: Vendor Source Code

[Timothy Sipples]

John Gilmore writes:
>The enumeration of their possible deficiencies is thus not an argument
>for eschewing [escrow] agreements.  It is an argument for retaining
>the services of able, appropriately experienced lawyers to draft them.

I'd add that even the most experienced lawyers frequently need help from
competent, non-lawyer technical advisors. Preferably pre-contract, not only
post-contract.


Timothy Sipples
IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA
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: REXX EDIT of Source Code

[Jon Perryman]

Why do you expect columns 1 to 6 to contain nulls (X'00')? The editor uses 
blanks. Am I misunderstanding something?

Jon Perryman.

On Friday, May 9, 2014 9:28 AM, Jon Butler  wrote:
 
The dataset in question is myid.ispf.pli, so the low-level qualifier is for 
PL/I.  In fact, I have set the HILIGHT to PLI.  In the ISPF editor everything 
works as it should.  There are no line numbers in columns 1-6 becuase there are 
PL/I or *PROCESS statements there.  There are also no line numbers in 73-80.  I 
run a Mod 5 terminal, so there are no "hidden" columns.  WYSIWIG in ISPF.
>
>The data set has the ISPF PROFILE attributes PLI (FIXED -80), NUMBER OFF, 
>AUTONUM OFF, IMACRO NONE, MARGINS(2,80).  I still get the first six columns 
>blanked outset to x'40' not x'00'.
>

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

Re: EZZ9308E UNRESPONSIVE NAME SERVER

[Jon Perryman]

Increasing the DSN timeout may adversely affect your system and it may not be 
apparent. Be very cautious when changing this parm.

It was mentioned that this error does not always occur. The reason for this is 
that the name is resolved in a DNS that occurs before the problematic DNS 
server. To cause the error message, you can ping a name that does not exist. 
This can also be sporadic for names that are dynamically added/removed in the 
DNS server. You may have times when the name does not exist in the expected DNS 
server. During this time, that name will have have this error.
 
Products sometimes will terminate if they don't start within reasonable amount 
of time. If one of those products has multiple connections that fails with this 
error, then increasing the timeout could push the startup time past the startup 
time threshold.

Even if your products don't terminate, you may still have a started task 
manager running. For tasks it manages, there is a startup time threshold. 
Depending on the action, it could cause the product to restart. This often 
occurs during IPL so you may drastically increase IPL time or you may be 
missing critical started tasks.

Automation could also be a problem. Some sites ping various destinations to 
ensure they are still active. I've seen some scheduled as often as every 10 
seconds. The extra delay could cause a backlog of automation exec's and cause 
critical automation to be delayed.  

Jon Perryman

On Thursday, May 8, 2014 5:08 AM, Keith Smith  wrote:
 
I have doubled the amount of time that it gathers attempts to calculate
>the percentage *and the time it allows for an attempt to be considered a
>failure.*
>
>On Thu, May 8, 2014 at 7:52 AM, Keith Smith  wrote:
>
>> I have had the same problem. I am sure it is network related but my
>> network folks say nothing has changed... to that I say... why did it just
>> start occurring without any change anywhere.
>

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

Re: Tools - APF updates

[Jon Perryman]

You are taking quite a risk for very little benefit.

First, no one has mentioned using REXX EXECIO could be disastrous. Seldom do we 
think about edit's feature where it creates a temp member and renames it after 
the member is updated. If you use EXECIO, your member will contain whatever is 
written up to the point of failure. E.g. parmlib get's full while trying to 
write. At the very least, you should write this as an edit macro. 

Since we don't know what you are including in this exec, there may be other 
things we have not considered.

Jon Perryman.

On Saturday, May 10, 2014 12:24 PM, mf db  wrote:
 
Thank you lucas for your input.  I was looking a similar solutions.
>On 11 May 2014 00:51, "Lucas Rosalen"  wrote:
>
>> It looks to me he wants/need some sort of panel-based program where you
>> would input a loadlib name, volume and sulfix of PROGxx, then it would
>> automatically update PROGxx with that APF entry.
>> At least this was my understanding.
>

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

Re: Vendor Source Code

[Shmuel Metz (Seymour J.)]

In , on 05/10/2014
   at 10:38 PM, Ed Gould  said:

>I had a few occurrences of looking at code that way. After looking 
>at a IFCEREP1 module I found a really bad code sequence (causing 
>cpu usage to sky rocket when running a specific report)

Yes, but at the Technion fixing stupid code[11] was a nice exercise
for the students, and you couldn't beat the OS/360 and SVS service
aids for that purpose. Take AMBLIST - please!

[1] I'm talking orders of magnitude.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: Vendor Source Code

[Shmuel Metz (Seymour J.)]

In <3833201874748634.wa.ibmmaintpg.com...@listserv.ua.edu>, on
05/10/2014
   at 06:00 PM, Shane Ginnane  said:

>I do however recall sitting down at a (very old) fiche reader in 
>the computer room at one time looking through the source for 
>IEBCOPY. Hard way to read code.

I never had any trouble reading the microfiche. However, if I need to
correct or enhance the code then I want current source, not just a
compile listing.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: Good News: Introducing Mobile Workload Pricing (MWP) for z/OS

[Timothy Sipples]

Roger Lowe asks:
>Surely, the functionality of MWRT could have been added to SCRT so
>that us customers could keep running it on z/OS?

IBM did that, as I understand it -- and I thought I explained that, but
I'll try again. SCRT also has a Microsoft Windows-based tool component.
MWRT is a *replacement* for that Windows-based SCRT component. If you're
using MWRT, you don't have to also use SCRT (the Windows tool). This is
path augmentation, not path duplication. For those of you who are not going
to use MWRT, it's business as usual (SCRT).

Think of this as SCRT Standard Edition and SCRT Advanced Edition (MWRT),
basically. For now, at least, there will be two tools/paths with MWRT a
perfect superset of SCRT.

If the Microsoft Windows desktop/laptop requirement for SCRT/MWRT is not a
good requirement, let IBM know through the appropriate channels.

Radoslaw Skorupka asks:
>How can the tool recognize which transactions are mobile?

Aled Hughes remarks:
>I may be stupid, but I have yet to understand the basics - what
>is defined as a 'mobile transaction'.

I thought I was clear on that point, too, but I'll try again. If *you* can
distinguish between a mobile transaction and a non-mobile transaction, IBM
is willing to at least discuss the measurement and reporting processes.
Both you and IBM sit down to agree on a measurement plan consistent with
IBM's views of the term "mobile transaction." If that measurement plan is
"reasonable," it'll probably be approved.

For those of you still scratching your heads thinking that's a "radical"
notion, it's not. As long as the definitions are well understood, and as
long as you and IBM can measure (and if necessary audit) against those
definitions, there should be no particular impediment. Most of you already
know how many of your customers are arriving via iOS devices, and how many
are arriving via Android devices, and how many are arriving via
Blackberries, and so on. Most of you probably already know the nature and
number of CICS transactions (for example) attributable to each of those
devices (or at least those devices collectively). If you do, great, work
out a measurement and reporting plan with IBM. If you don't, that might be
a problem already (for customer service, capacity planning, and/or security
reasons), and now you've got some additional incentive to address those
possible gaps.

One of my IBM colleagues provided me with some additional information over
the weekend. MWP is even better than I described. Here are the points of
clarification (in no particular order):

1. MWP is actually the *third* sub-sub-capacity licensing innovation. The
first was Getting Started Sub-Capacity Pricing (GSSP), then IWP arrived,
now MWP. (I wrote that MWP was the second sub-LPAR sub-capacity licensing
option from IBM, but it's actually the third.) A lot of you said you didn't
always like having separate LPARs for separate licensing, and IBM continues
to respond to your requests.

2. MWP *can* apply to zNALC LPARs. If you have a z/OS LPAR (zNALC or not)
with only z/OS (and z/OS elements) but no other IBM products, then MWP
doesn't apply. I stated that correctly. But if you have a qualified zNALC
LPAR with other IBM products (e.g. DB2 for z/OS) licensed via AWLC or AEWLC
or sub-capacity IPLA, *yes*, MWP *can* apply to those other products. Good
news again.

3. Relatedly, MWRT will adjust the MSUs downward for *all* sub-capacity
eligible IBM products running on z/OS, based on measured "mobile
transactions" as agreed with IBM. Yes, that includes sub-capacity IBM
International Program License Agreement (IPLA) products. To pick an
example, if you're running IBM Integration Bus for z/OS (formerly known as
WebSphere Message Broker for z/OS), MWRT can adjust that product's reported
MSUs, too, based on mobile use of Integration Bus's services. Your IBM CICS
tools are adjusted with your CICS, your IBM IMS tools with your IMS, your
IBM DB2 tools with your DB2, your IBM MQ tools with your MQ, your ACLS
It's across the (z/OS-based) board, according to the amount of workload
classed as "mobile transactions" (as agreed with IBM), excluding only z/OS
and z/OS elements. It's not only the big IBM products I listed. Everything
IBM that's (a) sub-capacity eligible, (b) riding on z/OS, (c) with mobile
activity. Very good news.

4. Sysplex qualification rules are unaffected, as I wrote. I really should
not have mentioned Sysplex aggregation rules so close together with
SCRT/MWRT measurements since Sysplex qualification and the "50% rule" are
measured quite differently. But, to reiterate, nothing changes there -- and
that's good. You wouldn't want MWP to suddenly make you ineligible for
Sysplex aggregation as your billed MSUs drop, and it doesn't -- MWP has no
impact on those rules.

To respond to the comments about licensing complexity, I think I addressed
that adequately, too, but I'll try again. MWP shouldn't require much work
to adopt, and the work it requires versus status quo should be of a

Re: Vendor Source Code

[John Gilmore]

Joel,

As I have tried to make clear, I think not.  The law is imperfect like
other institutions, but Dickens was quite wrong.  It is not, or not
always, an ass.

In my view at any rate this discussion has exhausted itself in
banalities, as is too often the case here.  I will leave it to others
to continue it, if indeed it is to be continued.

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: Vendor Source Code

[Paul Gilmartin]

On Sun, 11 May 2014 15:11:30 -0500, Joel C. Ewing wrote:
>
>If escrow agreements are yet another area where the law and expensive
>lawyers can't be relied on to produce the best common sense outcome,
>then perhaps the more apt quote in this context would be "the law is an
>ass".
> 
Kenneth Arrow axiomatically dispelled the notion that "the best common
sense outcome" can algorithmically be achieved.

-- gil

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

Re: Vendor Source Code

[Joel C. Ewing]

On 05/11/2014 11:34 AM, John Gilmore wrote:
> The only element of novelty in the notion that "not all of the lawyers
> in the world can foretell . . . " is its hyperbole.
>
> Justice Holmes long ago defined the law as "an informed guess as to
> what the courts will enforce in given circumstances"; and this element
> of indeterminacy, larger in some areas than in others, does need to be
> kept in mind.
>
> It is not, however, a bar to much of anything.  Charles Mills
> apparently dislikes escrow agreements, and he is free to try to avoid
> them where he can.  As a great physicist put the matter, "He is
> entitled to his own opinions, but is not to his own facts".
>
> John Gilmore, Ashland, MA 01721 - USA
>
> ...
If escrow agreements are yet another area where the law and expensive
lawyers can't be relied on to produce the best common sense outcome,
then perhaps the more apt quote in this context would be "the law is an
ass".

-- 
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: Handle RACF abend in LE C

[Gabor Hoffer]

Hi,

I've just checked my program and i think I've found the root of the
problem. I use an asm module to list members in a pds and probably my
program crashes in this code ( not ESTAE handling), not in fopen().
I've made a tiny testprogram and to verify it, and fopen() works as
expected, returns NULL and errno is set: 92-EDC5092I An I/O abend was
trapped.

Thank for your help!

Regards,
Gabor


On Sun, May 11, 2014 at 11:25 AM, Robert S. Hansel (RSH) <
r.han...@rshconsulting.com> wrote:

> Gabor,
>
> It may be crashing because your ID apparently has access to FACILITY
> resource BPX.SERVER, which requires a 'clean' program environment (i.e.,
> all programs must either be in LPA or defined by a PROGRAM class profile),
> and it is trying to load undefined programs. See the ICH422I messages.
> You'll either need to define the programs with their associated libraries
> to RACF or, unless you are specifically trying to create a daemon that
> needs BPX.SERVER authority, remove your access to the latter.
>
> Regards, Bob
>
> Robert S. Hansel
> Lead RACF Specialist
> RSH Consulting, Inc.
> 617-969-8211
> www.linkedin.com/in/roberthansel
> http://twitter.com/RSH_RACF
> www.rshconsulting.com
> ---
> 2014 RACF Training
> - Audit & Compliance Roadmap - Boston - OCT 27-30, 2014
> - Intro & Basic Admin - WebEx - JUN 9-13, 2014
> - Intro & Basic Admin - WebEx - DEC 8-12, 2014
> - Securing z/OS UNIX  - WebEx - SEPT 30 - OCT 3, 2014
> ---
>
> -Original Message-
> Date:Sat, 10 May 2014 13:27:28 +0200
> From:Gabor Hoffer 
> Subject: Handle RACF abend in LE C
>
> Hello,
>
> I have a LE C program that crashes if I try to open a dataset that is not
> allowed to read with my user. How can I catche and ( handle in C) this type
> of error?
>
> 13.19.56 JOB08022  ICH408I USER(GAH2) GROUP(SYS1) NAME(GAH2
>064   GAH.NOACCESS.PDS CL(DATASET ) VOL(DSK30E)
>064   INSUFFICIENT ACCESS AUTHORITY
>064   FROM GAH.NOACCESS.PDS (G)
>064   ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )
> 13.19.56 JOB08022  IEC150I
> 913-38,IFG0194E,GEX1,AGENT,SYS00079,030E,DSK30E,GAH.N
> 13.19.56 JOB08022  CEE0374C CONDITION = CEE3250C TOKEN = 00040CB2 61C3C5C5
> 0
>066  WHILE RUNNING PROGRAM UCXJM25
>066  AT THE TIME OF INTERRUPT
>066  PSW 078D0400 800A3FCC
>066  GPR 0-3 00166D14 001667D8 00166A98 
>066  GPR 4-7  0008 0004 0BA47038
>066  GPR 8-B 0D02E220 000207F0 0D02E220 000A3650
>066  GPR C-F 00166D20 00166760 800A3F74 
>066  FLT 0-2 4E81536E0B5C  
>066  FLT 4-6   
> 13.19.56 JOB08022  BPXP011I THREAD 0BD5D9B80003, IN PROCESS 50397294,
> WAS  0
>072 TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
> 13.19.56 JOB08022  BPXP011I THREAD 0BD5E644, IN PROCESS 50397294,
> WAS  0
>073 TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
> 13.19.56 JOB08022  BPXP011I THREAD 0BD5F2C80005, IN PROCESS 50397294,
> WAS  0
>074 TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
> 13.19.56 JOB08022  BPXP011I THREAD 0BD5A7980002, IN PROCESS 50397294,
> WAS  0
>075 TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
> 13.19.56 JOB08022  BPXP011I THREAD 0BD59B11, IN PROCESS 50397294,
> WAS  0
>076 TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
> 13.19.56 JOB08022  ICH422I THE ENVIRONMENT CANNOT BECOME UNCONTROLLED.
> 13.19.56 JOB08022  CSV042I REQUESTED MODULE IEAVTRP2 NOT ACCESSED. THE
> MODULE IS
> 13.19.56 JOB08022  BPXP014I ENVIRONMENT MUST REMAIN CONTROLLED FOR SERVER
> (BPX.S
> 13.19.56 JOB08022  CSV042I REQUESTED MODULE IEAVTRF4 NOT ACCESSED. THE
> MODULE IS
> 13.19.56 JOB08022  ICH422I THE ENVIRONMENT CANNOT BECOME UNCONTROLLED.
> 13.19.56 JOB08022  BPXP014I ENVIRONMENT MUST REMAIN CONTROLLED FOR SERVER
> (BPX.S
>
> Thanks and reagrds,
> Gabor
>
> --
> 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: Vendor Source Code

[John Gilmore]

The only element of novelty in the notion that "not all of the lawyers
in the world can foretell . . . " is its hyperbole.

Justice Holmes long ago defined the law as "an informed guess as to
what the courts will enforce in given circumstances"; and this element
of indeterminacy, larger in some areas than in others, does need to be
kept in mind.

It is not, however, a bar to much of anything.  Charles Mills
apparently dislikes escrow agreements, and he is free to try to avoid
them where he can.  As a great physicist put the matter, "He is
entitled to his own opinions, but is not to his own facts".

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: Vendor Source Code

[Paul Gilmartin]

On Sun, 11 May 2014 00:57:05 -0400, Tony Harminc wrote:

>On 10 May 2014 15:58, Ed Jaffe wrote:
>> FWIW, I don't think the source code for Program Products like ADRDSSU was
>> available even in the pre-OCO days.
>
>Some IBM Program Products had source code available from the earliest
>days. For example, the PL/I Optimizing compiler had source code that
>was simply orderable as an option. ...
> 
Is that from the (legendary?) era when IBM attempted to tell customers
that the specification of the language could be inferred by reading the
source code of the compiler?

Eliminates bug reports: whatever the compiler does is ipso facto
correct.

> ... The same was true of ACF/VTAM and
>many other quite mainstream products. Program Product versions of
>JES2, and of course VM, continued for a long time not only to have
>source available, but to be source maintained.
>
>But when the OCO is a Good Thing meme got entrenched in the early
>1980s, new IBM code - priced or not - mostly did not have continued
>source availability.

-- gil

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

Re: Vendor Source Code

[Paul Gilmartin]

On Sat, 10 May 2014 15:03:11 -0500, John McKown wrote:
>
>Go Debian!
>It installs from source.
>
Thereby validating it.  VM (used to be?) that way.

On Sat, 10 May 2014 22:38:01 -0500, Ed Gould wrote:
>
>I had a few occurrences of looking at code that way. After looking at
>a IFCEREP1 module I found a really bad code sequence (causing cpu
>usage to sky rocket when running a specific report) The damn module
>did a sequential  table look up that was absolutely terrible. It
>could have been handled with very few instructions with a load and a
>shift left double. For each device it looped through a table.
>Something a rookie would have done. I tried to apar it and they
>refused to take it as a performance issue. Fast forward 20+ years and
>the damn module still sucks up cpu  time. No one cares.
> 
I once did likewise, wondering why CLIST was so slow.  A colleague's
execution profiling utility located the culprit: the character fetch
routine in lexical analysis (JWG knows the principle well):
BALR; STM; GETMAIN; chain; IC; STC; unchain; LM; FREEMAIN;
BR14 (roughly, from memory) for each character!  An egregious
misuse of coding standards.

>On May 10, 2014, at 6:00 PM, Shane Ginnane wrote:
>
>> I do however recall sitting down at a (very old) fiche reader in
>> the computer room at one time looking through the source for
>> IEBCOPY. Hard way to read code.
>> Can't remember if we had an actual problem, of it was just a "I
>> wonder" moment.

-- gil

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

Re: Vendor Source Code

[Charles Mills]

All the lawyers in the world cannot foretell with certainty what a court
will decide (under the suasions of other lawyers). That quite seriously is
the fundamental problem with escrow. 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Saturday, May 10, 2014 10:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Vendor Source Code

In
,
on 05/09/2014
   at 06:35 AM, John McKown  said:

>This has been an interesting thread. I rather like the escrow idea.

I like it, but only if both sides have had bankruptcy lawyers verify that
the source code *will* be provided in a timely fashion when the agreement
calls for it and that it will *not* be provided to a third party as the
result of court action, e.g., if the escrow agent goes bankrupt.

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

Re: Vendor Source Code

[Paul Gilmartin]

On Sat, 10 May 2014 14:01:56 -0400, John Gilmore wrote:
>
>Emphasis does, however, need to be placed on the pronoun 'someone'.
>If this code had been available not just to someone but to all of us,
>quite rapid progress might well have been made with a problem
>perceived to be important to the community.   I will suppress the
>old-codger war stories; but in the days of MVT, i.e., before OCO, this
>did happen on a number of occasions.
> 
Linus's Law (apparently a misattribution due to Eric S. Raymond):

"Given enough eyeballs, all bugs are shallow"

-- gil

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

Re: Vendor Source Code

[Shmuel Metz (Seymour J.)]

In
,
on 05/09/2014
   at 06:35 AM, John McKown  said:

>This has been an interesting thread. I rather like the escrow idea.

I like it, but only if both sides have had bankruptcy lawyers verify
that the source code *will* be provided in a timely fashion when the
agreement calls for it and that it will *not* be provided to a third
party as the result of court action, e.g., if the escrow agent goes
bankrupt.

I'm not concerned with the learning curve[1] if the worst happens, but
the agreement should include documentation and currency.

[1] The same issue exists if the development team is wiped out[2]
in an accident.

[2] I once had to work on a large program whose author was into
auto racing; he wound up in a coma for several years.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: Re : Setting A SLIP For A Program Running Under CICS.

[Shmuel Metz (Seymour J.)]

In
,
on 05/09/2014
   at 07:11 AM, Peter Relson  said:

>You must find out from CICS how to determine the address of your
>module.

If he can make a business case for it, he might want to submit a
requirement for SLIP support of CICS dynamic loading.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: Vendor Source Code

[Shmuel Metz (Seymour J.)]

In <536e84dd.8020...@phoenixsoftware.com>, on 05/10/2014
   at 12:58 PM, Ed Jaffe  said:

>FWIW, I don't think the source code for Program Products like 
>ADRDSSU was available even in the pre-OCO days.

All the program products that I used in those days came with feature
codes for source at release boundaries. There were compile listings on
microfiche for service, but no machine-readable source, except for
those products where the maintenance was at the source level.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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: Vendor Source Code

[Ed Gould]

Spoken like a ex lawyer.

Ed
On May 11, 2014, at 8:00 AM, John Gilmore wrote:


All contracts, whether they be escrow agreements or prenuptial ones,
vary in quality as a function of the talent, experience in a milieu,
and knowledge of the lawyers who draft them.

The enumeration of their possible deficiencies is thus not an argument
for eschewing [escrow] agreements.  It is an argument for retaining
the services of able, appropriately experienced lawyers to draft them.

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: System z StackExchange proposal

[Scott Ford]

Searches are one thing, but much much more is exchanged on the Listserv. 
Especially for us who haven't had the fortune to meet each other at Share

Scott ford
www.identityforge.com
from my IPAD




> On May 10, 2014, at 7:12 PM, Shane Ginnane  wrote:
> 
>> On Sat, 10 May 2014 17:11:11 -0400, John Gilmore wrote:
>> 
>> I did look through all of the questions that have so far been raised
>> in this new StackExchange forum.
> 
> I'm sure most of us have. My initial response to most was RTFM, so I'll stay 
> away.
> They do usually make a good resource for later 'net searches, so will have 
> value. Quite often they wind up being quite aggressively moderated.
> 
> --
> 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: Vendor Source Code

[Charles Mills]

Amen!

The only thing I might quibble with in Tony's reply:

> Escrow agreements are generally part of the contract between vendor and 
> customer, and require
> in turn that the vendor maintain an agreement with an acceptable escrow 
> company. (In passing,
> there are fewer escrow companies now than there were say ten years ago.) 
> Usually the customer
> has no direct relationship with the escrow company, and so -- as Charles 
> Mills points out -- 
> will end up arguing with other creditors in bankruptcy court over the assets.

Mostly, I have seen three-party agreements, with the vendor, the agent and the 
customer all as signatories.

But even if the customer is a signatory, I believe that a court would question 
whether the agreement was "executory" -- subject to being torn up by bankruptcy.

Yes, there are fewer escrow agents than formerly. Consolidation, like in most 
industries? Or have customers decided that escrow is not worth the hassle?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Saturday, May 10, 2014 10:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Vendor Source Code

On 8 May 2014 22:09, Mitch  wrote:
> And for the likes of the larger ISVs, I would guess all of their 
>product source code is in escrow and kept up to date.  Maybe not so 
>much for the "mom and pop" software companies, but the big ones, yes.

I think it's exactly the "mom and pop" ISVs that are more likely to be required 
by buyers to have escrow arrangements in place. Few companies are in a position 
to require e.g. IBM to do much of anything.

...

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

Re: Vendor Source Code

[John Gilmore]

All contracts, whether they be escrow agreements or prenuptial ones,
vary in quality as a function of the talent, experience in a milieu,
and knowledge of the lawyers who draft them.

The enumeration of their possible deficiencies is thus not an argument
for eschewing [escrow] agreements.  It is an argument for retaining
the services of able, appropriately experienced lawyers to draft them.

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: Handle RACF abend in LE C

[Robert S. Hansel (RSH)]

Gabor,

It may be crashing because your ID apparently has access to FACILITY resource 
BPX.SERVER, which requires a 'clean' program environment (i.e., all programs 
must either be in LPA or defined by a PROGRAM class profile), and it is trying 
to load undefined programs. See the ICH422I messages. You'll either need to 
define the programs with their associated libraries to RACF or, unless you are 
specifically trying to create a daemon that needs BPX.SERVER authority, remove 
your access to the latter.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com
---
2014 RACF Training
- Audit & Compliance Roadmap - Boston - OCT 27-30, 2014
- Intro & Basic Admin - WebEx - JUN 9-13, 2014
- Intro & Basic Admin - WebEx - DEC 8-12, 2014
- Securing z/OS UNIX  - WebEx - SEPT 30 - OCT 3, 2014
---

-Original Message-
Date:Sat, 10 May 2014 13:27:28 +0200
From:Gabor Hoffer 
Subject: Handle RACF abend in LE C

Hello,

I have a LE C program that crashes if I try to open a dataset that is not
allowed to read with my user. How can I catche and ( handle in C) this type
of error?

13.19.56 JOB08022  ICH408I USER(GAH2) GROUP(SYS1) NAME(GAH2
   064   GAH.NOACCESS.PDS CL(DATASET ) VOL(DSK30E)
   064   INSUFFICIENT ACCESS AUTHORITY
   064   FROM GAH.NOACCESS.PDS (G)
   064   ACCESS INTENT(READ   )  ACCESS ALLOWED(NONE   )
13.19.56 JOB08022  IEC150I
913-38,IFG0194E,GEX1,AGENT,SYS00079,030E,DSK30E,GAH.N
13.19.56 JOB08022  CEE0374C CONDITION = CEE3250C TOKEN = 00040CB2 61C3C5C5
0
   066  WHILE RUNNING PROGRAM UCXJM25
   066  AT THE TIME OF INTERRUPT
   066  PSW 078D0400 800A3FCC
   066  GPR 0-3 00166D14 001667D8 00166A98 
   066  GPR 4-7  0008 0004 0BA47038
   066  GPR 8-B 0D02E220 000207F0 0D02E220 000A3650
   066  GPR C-F 00166D20 00166760 800A3F74 
   066  FLT 0-2 4E81536E0B5C  
   066  FLT 4-6   
13.19.56 JOB08022  BPXP011I THREAD 0BD5D9B80003, IN PROCESS 50397294,
WAS  0
   072 TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
13.19.56 JOB08022  BPXP011I THREAD 0BD5E644, IN PROCESS 50397294,
WAS  0
   073 TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
13.19.56 JOB08022  BPXP011I THREAD 0BD5F2C80005, IN PROCESS 50397294,
WAS  0
   074 TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
13.19.56 JOB08022  BPXP011I THREAD 0BD5A7980002, IN PROCESS 50397294,
WAS  0
   075 TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
13.19.56 JOB08022  BPXP011I THREAD 0BD59B11, IN PROCESS 50397294,
WAS  0
   076 TERMINATED DUE TO A PTHREAD QUIESCE OF TYPE 2.
13.19.56 JOB08022  ICH422I THE ENVIRONMENT CANNOT BECOME UNCONTROLLED.
13.19.56 JOB08022  CSV042I REQUESTED MODULE IEAVTRP2 NOT ACCESSED. THE
MODULE IS
13.19.56 JOB08022  BPXP014I ENVIRONMENT MUST REMAIN CONTROLLED FOR SERVER
(BPX.S
13.19.56 JOB08022  CSV042I REQUESTED MODULE IEAVTRF4 NOT ACCESSED. THE
MODULE IS
13.19.56 JOB08022  ICH422I THE ENVIRONMENT CANNOT BECOME UNCONTROLLED.
13.19.56 JOB08022  BPXP014I ENVIRONMENT MUST REMAIN CONTROLLED FOR SERVER
(BPX.S

Thanks and reagrds,
Gabor

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