Redirecting Software Functionality

2006-02-15 Thread Jerry Vernon
Hi,

We are trying to restrict the execution of certain programs by LPAR so we
can just license them by processor.  The one in particular we are looking
at is COBOL. By limiting COBOL compiles to one Development LPAR.  Does
anyone know of any software that can be used to do this?

Thank you ahead of time.

Jerry Vernon
(206) 377-1257
[EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-15 Thread Imbriale, Donald (Exchange)
Are the data sets in linklist?
Are the data sets in the master catalog?
Is the master catalog shared by more than one system?
Is the sysres shared by more than one system?
Is PARMLIB shared by more than one system?


Don Imbriale

>-Original Message-
>From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
>Of Jerry Vernon
>Sent: Wednesday, February 15, 2006 5:33 PM
>To: IBM-MAIN@BAMA.UA.EDU
>Subject: Redirecting Software Functionality
>
>Hi,
>
>We are trying to restrict the execution of certain programs by LPAR so
we
>can just license them by processor.  The one in particular we are
looking
>at is COBOL. By limiting COBOL compiles to one Development LPAR.  Does
>anyone know of any software that can be used to do this?
>
>Thank you ahead of time.
>
>Jerry Vernon
>(206) 377-1257
>[EMAIL PROTECTED]


***
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-15 Thread McKown, John
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Vernon
> Sent: Wednesday, February 15, 2006 4:33 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Redirecting Software Functionality
> 
> 
> Hi,
> 
> We are trying to restrict the execution of certain programs 
> by LPAR so we
> can just license them by processor.  The one in particular we 
> are looking
> at is COBOL. By limiting COBOL compiles to one Development LPAR.  Does
> anyone know of any software that can be used to do this?
> 
> Thank you ahead of time.
> 
> Jerry Vernon
> (206) 377-1257
> [EMAIL PROTECTED]

Some ideas, which may sound a bit silly, but I don't know your
environment.

Don't put the COBOL compiler libraries on the other LPARs?
Put them on DASD that is kept offline to the other LPARs?
Implement IEFUSI exit and abend the job if you detect PGM=IGYCRCTL?
Implement the JES2 exit 6 and JCL error if you detect PGM=IGYCRCTL (Can
the ThruPut Manager product do it, anyone?)

I don't really know of any product, per se, to do this. Oh, ACF2 might
be able to do it with a conditional access list to the COBOL compiler
libraries. RACF cannot do this conditioning based on LPAR. This assumes
that you are sharing the RACF database amoung the LPARs. If you are not
sharing the RACF database, then use RACF to protect the COBOL libraries.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-15 Thread Brian Peterson
ThruPut Manager will do this very easily.

I've heard of sites who use WLM Scheduling Environments to accomlish
similar results, as well.

The prior suggestions of a JES2 exit, plus the suggestion of a WLM
scheduling environment, might be a pretty good "roll your own" solution.

Brian

On Wed, 15 Feb 2006 16:32:48 -0600, Jerry Vernon <[EMAIL PROTECTED]>
wrote:

>Hi,
>
>We are trying to restrict the execution of certain programs by LPAR so we
>can just license them by processor.  The one in particular we are looking
>at is COBOL. By limiting COBOL compiles to one Development LPAR.  Does
>anyone know of any software that can be used to do this?
>
>Thank you ahead of time.
>
>Jerry Vernon

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-15 Thread Ed Gould

On Feb 15, 2006, at 4:39 PM, Imbriale, Donald (Exchange) wrote:


Are the data sets in linklist?
Are the data sets in the master catalog?
Is the master catalog shared by more than one system?
Is the sysres shared by more than one system?
Is PARMLIB shared by more than one system?

---SNIP-


Don,

This is fine for a high level yes/no.

But programmers can be fairly tricky. I have seen iebcopy of the  
contents of the compiler (as well as the syslib  of LE) done so they  
can get around restrictions (like your entry).


There is no real fool proof way of stopping it unless the compiler &  
runtime (LE) can be "enforced" by iefprdxx(PARMLIB Member) (right  
member name?). It still doesn't help with back level compilers (etc).


IBM can be asked to do so, if they will do it, is another ball of wax.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-15 Thread Ed Gould

On Feb 15, 2006, at 5:13 PM, Brian Peterson wrote:


ThruPut Manager will do this very easily.

I've heard of sites who use WLM Scheduling Environments to accomlish
similar results, as well.

The prior suggestions of a JES2 exit, plus the suggestion of a WLM
scheduling environment, might be a pretty good "roll your own"  
solution.


Brian



Brian,

They can always rename the compiler (I have seen this done) with a  
copy in thier own steplib.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-15 Thread Jerry Whitteridge
OSEM from Trident Services can do what you are looking for.
(http://www.triserve.com)
We use it to restrict SAS to one LPAR as an example. I did a
presentation at Share Anaheim on the product and its use. 


On Wed, 2006-02-15 at 16:32 -0600, Jerry Vernon wrote:
> Hi,
> 
> We are trying to restrict the execution of certain programs by LPAR so we
> can just license them by processor.  The one in particular we are looking
> at is COBOL. By limiting COBOL compiles to one Development LPAR.  Does
> anyone know of any software that can be used to do this?
> 
> Thank you ahead of time.
> 
> Jerry Vernon
> (206) 377-1257
> [EMAIL PROTECTED]
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
-- 
Jerry Whitteridge
Safeway Inc.
PH: 925 951 4184
Fax:925 951 4204

"MMS " made the following annotations.
--
Warning: 
All e-mail sent to this address will be received by the Safeway corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain information proprietary to Safeway and is 
intended only for the use of the intended recipient(s).  If the reader of this 
message is not the intended recipient(s), you are notified that you have 
received this message in error and that any review, dissemination, distribution 
or copying of this message is strictly prohibited.  If you have received this 
message in error, please notify the sender immediately. 
  
==

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-15 Thread Scott Barry
The ISV MVS Solutions Inc. has a software product ThruPut Manager which
provides user-defined intelligent job routing and much more, such as
resource staging (prior to job-initiation) including production support for
virtual volume staging as well as DFHSM HRECALLs and silo/rack tape volume
staging.  Other functions relating to INIT throttling and setting execution
limits help manage your end-users who insist on submitting their daily 25
hours from a single TSO SUBMIT member.  I personally work with a client that
uses ThruPut Manager to direct SAS jobs to a specific LPAR (limited capacity
for software licensing reasons).

You can find more information at the links below.

Sincerely,

Scott Barry
SBBWorks, Inc.

http://www.mvssol.com/

http://www.zjournal.com/PDF/vogt.pdf



Jerry Vernon said:

Hi,

We are trying to restrict the execution of certain programs by LPAR so we
can just license them by processor.  The one in particular we are looking
at is COBOL. By limiting COBOL compiles to one Development LPAR.  Does
anyone know of any software that can be used to do this?

Thank you ahead of time.

Jerry Vernon
(206) 377-1257

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-15 Thread tony babonas
we also restrict SAS to  1 lpar for contractual
reasons.  we have CA/Top Secret so we can restrict
programs and datasets by SMF IDs. 

-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Jerry
Whitteridge
Sent: Wednesday, February 15, 2006 5:18 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Redirecting Software Functionality

OSEM from Trident Services can do what you are looking
for.
(http://www.triserve.com)
We use it to restrict SAS to one LPAR as an example. I
did a presentation at Share Anaheim on the product and
its use. 


On Wed, 2006-02-15 at 16:32 -0600, Jerry Vernon wrote:
> Hi,
> 
> We are trying to restrict the execution of certain
programs by LPAR so 
> we can just license them by processor.  The one in
particular we are 
> looking at is COBOL. By limiting COBOL compiles to
one Development 
> LPAR.  Does anyone know of any software that can be
used to do this?
> 
> Thank you ahead of time.
> 
> Jerry Vernon
> (206) 377-1257
> [EMAIL PROTECTED]
> 
>
---
---
> For IBM-MAIN subscribe / signoff / archive access
instructions, send 
> email to [EMAIL PROTECTED] with the message: GET
IBM-MAIN INFO 
> Search the archives at
http://bama.ua.edu/archives/ibm-main.html
> 
--
Jerry Whitteridge
Safeway Inc.
PH: 925 951 4184
Fax:925 951 4204

"MMS " made the following annotations.
---
---
Warning: 
All e-mail sent to this address will be received by the
Safeway corporate e-mail system, and is subject to
archival and review by someone other than the
recipient.  This e-mail may contain information
proprietary to Safeway and is intended only for the use
of the intended recipient(s).  If the reader of this
message is not the intended recipient(s), you are
notified that you have received this message in error
and that any review, dissemination, distribution or
copying of this message is strictly prohibited.  If you
have received this message in error, please notify the
sender immediately. 
  
===
===

---
---
For IBM-MAIN subscribe / signoff / archive access
instructions, send email to [EMAIL PROTECTED] with
the message: GET IBM-MAIN INFO Search the archives at
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Timothy Sipples
I wonder if IPLing z/OS as z/OS.e would do the trick.

- - - - -
Timothy F. Sipples
Consulting Enterprise Software Architect, z9/zSeries
IBM Japan, Ltd.
E-Mail: [EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Stefan Finka
Hi Tony,
We also have CA-Top Secret (8.0)and I tried doing this by protecting a
PROGRAM resource by SYSID. However, I found that CA removed this feature
from TSS 5.1 onwards for performance reasons. So, how exactly are you doing
this with TSS?
Thanks,
Stefan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Bob Shannon
>>We are trying to restrict the execution of certain programs by LPAR so
we
>>can just license them by processor.  The one in particular we are
looking
>>at is COBOL. By limiting COBOL compiles to one Development LPAR.  Does
>>anyone know of any software that can be used to do this?

>RACF cannot do this conditioning based on LPAR.

Protect access to the compiler by using the "WHEN(SYSID()..."
RACF parameter. Yes, RACF does support this. See the RACF
Administrator's Guide. If you want to get fancy, establish a Scheduling
Environment to allow easy access to the compiler. This solution is easy
and it's free.

Bob Shannon
Rocket Software
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Itschak Mugzach
I would protect IBM product usage by specifying their name in IFAPRDxx
with STATE(DISABLED). 

ITschak 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Bob Shannon
Sent: Thursday, February 16, 2006 1:49 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Redirecting Software Functionality


>>We are trying to restrict the execution of certain programs by LPAR so
we
>>can just license them by processor.  The one in particular we are
looking
>>at is COBOL. By limiting COBOL compiles to one Development LPAR.  Does
>>anyone know of any software that can be used to do this?

>RACF cannot do this conditioning based on LPAR.

Protect access to the compiler by using the "WHEN(SYSID()..."
RACF parameter. Yes, RACF does support this. See the RACF
Administrator's Guide. If you want to get fancy, establish a Scheduling
Environment to allow easy access to the compiler. This solution is easy
and it's free.

Bob Shannon
Rocket Software
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Schramm, Rob
restrict the dataset via CPUID. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Stefan Finka
Sent: Thursday, February 16, 2006 5:49 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Redirecting Software Functionality

Hi Tony,
We also have CA-Top Secret (8.0)and I tried doing this by protecting a
PROGRAM resource by SYSID. However, I found that CA removed this feature
from TSS 5.1 onwards for performance reasons. So, how exactly are you
doing this with TSS?
Thanks,
Stefan

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread John Eells

Timothy Sipples wrote:


I wonder if IPLing z/OS as z/OS.e would do the trick.




This would, of course, entail additional restrictions--not just 
the COBOL compiler--and I believe it would also require a change 
from a z/OS license to a z/OS.e license.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread John Eells

Itschak Mugzach wrote:


I would protect IBM product usage by specifying their name in IFAPRDxx
with STATE(DISABLED). 



This works only for products (and optional priced elements of 
z/OS) that use the IFAEDREG service.  I don't think the COBOL 
compiler is one of them.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Mark Jacobs
I just love standards. There are so many of them. I wish IBM and all the
vendors would agree on "ONE" method of product protection and have
everyone convert to that method.

It would make all our lives so much easier.

Mark Jacobs
Time Customer Service Inc.
Tampa, FL  

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of John Eells
Sent: Thursday, February 16, 2006 8:03 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Redirecting Software Functionality

Itschak Mugzach wrote:

> I would protect IBM product usage by specifying their name in IFAPRDxx
> with STATE(DISABLED). 


This works only for products (and optional priced elements of 
z/OS) that use the IFAEDREG service.  I don't think the COBOL 
compiler is one of them.

-- 
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Staller, Allan
AFAIK z/OS.e is exactly the same code as z/OS. The only
difference is what is allowed to be executed via IFAPRDxx
and contractual considerations.


I wonder if IPLing z/OS as z/OS.e would do the trick.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Walt Farrell

On 2/15/2006 5:32 PM, Jerry Vernon wrote:

We are trying to restrict the execution of certain programs by LPAR so we
can just license them by processor.  The one in particular we are looking
at is COBOL. By limiting COBOL compiles to one Development LPAR.  Does
anyone know of any software that can be used to do this?


You can do this with the program control features of RACF.  Define the 
main COBOL compiler module to RACF in the PROGRAM class, with a 
universal access (UACC) of NONE, and then do a conditional permission 
based on the system ID.


Example:

RDEFINE PROGRAM program-name ADDMEM('load-library-name'//NOPADCHK) 
UACC(NONE)


PERMIT program-name CLASS(PROGRAM) ID(*) ACCESS(READ) 
WHEN(SYSID(allowed-smf-id))


If you're concerned about programmers making their own copy of the 
compiler modules via IEBCOPY, then you can also protect the library 
containing the compiler.


ADDSD 'load-library-name' GENERIC UACC(EXECUTE)

The use of EXECUTE here will prevent users from opening the library to 
copy programs from it.  This approach will work best if the compiler 
library is in the system link list, but can also be made to work if your 
users need to access the library via a STEPLIB in batch.


It will be harder to make it work if you allow your users to run COBOL 
compiles in a TSO session.


Walt Farrell, CISSP
z/OS Security Design, IBM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread David Andrews
On Wed, 2006-02-15 at 17:14 -0600, Ed Gould wrote:
> But programmers can be fairly tricky. I have seen iebcopy of the  
> contents of the compiler (as well as the syslib  of LE) done so they  
> can get around restrictions (like your entry).

Then take 'em to HR and have 'em shot.  Seriously, this is a management
issue, not a technical one.  Implement roadblocks to prevent simple
mistakes, then put a couple bullets aside to take care of recalcitrant
individuals.  Zero tolerance: problem solved.

You CANNOT keep people around who knowingly bust license terms.

-- 
David Andrews
A. Duda and Sons, Inc.
[EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread McKown, John
> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews
> Sent: Thursday, February 16, 2006 8:20 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Redirecting Software Functionality
> 
> 
> On Wed, 2006-02-15 at 17:14 -0600, Ed Gould wrote:
> > But programmers can be fairly tricky. I have seen iebcopy of the  
> > contents of the compiler (as well as the syslib  of LE) 
> done so they  
> > can get around restrictions (like your entry).
> 
> Then take 'em to HR and have 'em shot.  Seriously, this is a 
> management
> issue, not a technical one.  Implement roadblocks to prevent simple
> mistakes, then put a couple bullets aside to take care of recalcitrant
> individuals.  Zero tolerance: problem solved.
> 
> You CANNOT keep people around who knowingly bust license terms.
> 
> -- 
> David Andrews

Totally agree. Been there, but was only able to force a "reprimand" on
the violator. Of course, he then learned what others tried to tell him:
"Don't P.O. the sysprog. It doesn't pay. He is usually smarter, meaner,
and sneaker than you." That one learned the hard way.

--
John McKown
Senior Systems Programmer
UICI Insurance Center
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Charles Mills
Sadly, the US Department of Justice would probably not allow this. They look
very much askance at dominant vendors getting together to talk about terms
of sale. Yeah, I know, it seems like all of the customers would benefit, but
it would be considered "restraint of trade." It would make life difficult
for a new entrant into the market who had a new and potentially competitive
way of licensing software.

Charles



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Mark Jacobs
Sent: Thursday, February 16, 2006 7:07 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Redirecting Software Functionality


I just love standards. There are so many of them. I wish IBM and all the
vendors would agree on "ONE" method of product protection and have
everyone convert to that method.

It would make all our lives so much easier.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Edward E. Jaffe

Mark Jacobs wrote:

I just love standards. There are so many of them. I wish IBM and all the
vendors would agree on "ONE" method of product protection and have
everyone convert to that method.
  


It was called IBM License Manager for z/OS. The idea was great; the 
implementation was a total disaster. It was pulled "from the shelves" 
never to be mentioned again ...



It would make all our lives so much easier.
  


That was the promise. The reality was quite different ...

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Ed Finnell
 
In a message dated 2/16/2006 7:07:28 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

vendors  would agree on "ONE" method of product protection and have
everyone convert  to that method.

It would make all our lives so much  easier.




>>
Heck then they could outsource us to  stanchekistan...:(((

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Mark Zelden
On Thu, 16 Feb 2006 08:07:17 -0500, Mark Jacobs <[EMAIL PROTECTED]>
wrote:

>I just love standards. There are so many of them. I wish IBM and all the
>vendors would agree on "ONE" method of product protection and have
>everyone convert to that method.
>
>It would make all our lives so much easier.
>

It's a nice dream.   I bet you can't even get to one standard for
many things in your own shop.  :-)

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Bob Rutledge
Other departments that have interest in this sort of behavior, at least where I 
work, are Loss Prevention and Risk Management.


Bob

David Andrews wrote:

On Wed, 2006-02-15 at 17:14 -0600, Ed Gould wrote:

But programmers can be fairly tricky. I have seen iebcopy of the  
contents of the compiler (as well as the syslib  of LE) done so they  
can get around restrictions (like your entry).



Then take 'em to HR and have 'em shot.  Seriously, this is a management
issue, not a technical one.  Implement roadblocks to prevent simple
mistakes, then put a couple bullets aside to take care of recalcitrant
individuals.  Zero tolerance: problem solved.

You CANNOT keep people around who knowingly bust license terms.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Ed Gould

On Feb 16, 2006, at 7:40 AM, Walt Farrell wrote:


On 2/15/2006 5:32 PM, Jerry Vernon wrote:
We are trying to restrict the execution of certain programs by  
LPAR so we
can just license them by processor.  The one in particular we are  
looking
at is COBOL. By limiting COBOL compiles to one Development LPAR.   
Does

anyone know of any software that can be used to do this?


You can do this with the program control features of RACF.  Define  
the main COBOL compiler module to RACF in the PROGRAM class, with a  
universal access (UACC) of NONE, and then do a conditional  
permission based on the system ID.


Example:

RDEFINE PROGRAM program-name ADDMEM('load-library-name'//NOPADCHK)  
UACC(NONE)


PERMIT program-name CLASS(PROGRAM) ID(*) ACCESS(READ) WHEN(SYSID 
(allowed-smf-id))


If you're concerned about programmers making their own copy of the  
compiler modules via IEBCOPY, then you can also protect the library  
containing the compiler.



Walt,

BTDT... didn't work.. You have to allow read/exec to the steplib.  
Once you have given that out its wide open.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Ed Gould

On Feb 16, 2006, at 8:19 AM, David Andrews wrote:


On Wed, 2006-02-15 at 17:14 -0600, Ed Gould wrote:

But programmers can be fairly tricky. I have seen iebcopy of the
contents of the compiler (as well as the syslib  of LE) done so they
can get around restrictions (like your entry).


Then take 'em to HR and have 'em shot.  Seriously, this is a  
management

issue, not a technical one.  Implement roadblocks to prevent simple
mistakes, then put a couple bullets aside to take care of recalcitrant
individuals.  Zero tolerance: problem solved.



Err... thats not an option in a highly political shop. Politics  
trumps all.


Ed




You CANNOT keep people around who knowingly bust license terms.

--
David Andrews
A. Duda and Sons, Inc.
[EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Hal Merritt
Don't forget our old friends in auditing. We are seeing these kinds of
questions. 

I agree: it is a management issue. And audit trumps politics. More, SOX
holds that the managers of the folks that get sneaky can be held
accountable. 

My $0.02. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Bob Rutledge
Sent: Thursday, February 16, 2006 12:21 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Redirecting Software Functionality

Other departments that have interest in this sort of behavior, at least
where I 
work, are Loss Prevention and Risk Management.

Bob

David Andrews wrote:
> On Wed, 2006-02-15 at 17:14 -0600, Ed Gould wrote:
> 
>>But programmers can be fairly tricky. I have seen iebcopy of the  
>>contents of the compiler (as well as the syslib  of LE) done so they  
>>can get around restrictions (like your entry).
> 
> 
> Then take 'em to HR and have 'em shot.  Seriously, this is a
management
> issue, not a technical one.  Implement roadblocks to prevent simple
> mistakes, then put a couple bullets aside to take care of recalcitrant
> individuals.  Zero tolerance: problem solved.
> 
> You CANNOT keep people around who knowingly bust license terms.
> 

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Ed Gould

On Feb 16, 2006, at 1:35 PM, Hal Merritt wrote:


Don't forget our old friends in auditing. We are seeing these kinds of
questions.

I agree: it is a management issue. And audit trumps politics. More,  
SOX

holds that the managers of the folks that get sneaky can be held
accountable.

My $0.02.



The other issue that I have seen in this that the copies of modules  
show up in a common library. It is close to impossible to pinpoint  
who put them there... Looking through SMF shows hundreds of updates  
and it gets worse as you don't know *WHEN* it happened. Unless you  
monitor the library on a daily basis it might be years before you run  
into the issue. If anyone knows of a way to stop it I would be happy  
to listen.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Chris Mason
Ed,

When I was last on a long-term consultancy, by example, I tried to encourage
a crude approach to documenting responsibility - and purpose - in a common
library by creating a member $$$INDEX. Each line in this member started with
the name of each member I added - or had been added by someone I worked with
and I was changing - to be followed by my name and a brief explanation of
why it was there. (The "$" signs at the beginning of the name ensured that
the member appeared first in the member list of course.) This was a
technique I used to use simply to keep track of my own work with my
test/education systems since I was very likely to forget work done years
before. The 8-character member name was never much help as documentation. I
even had .$$$INDEX data sets in which I listed my
data sets with explanations.

I expect if you made this a rule and devised some code to highlight any
undocumented member at the end of each day/week, you might have a management
tool to help keep track of who did what and why especially when the "who"
was unavoidably detained incommunicado for whatever reason.

Writing this up reminds me that the user name associated with members was
some gibberish that needed a lookup tool to translate to a person's name.
This must have been why putting the person's name in the description record
seemed like a good idea.

Maybe there are some products out there which claim to help with a process
such as this but there's no avoiding the necessary discipline of remembering
to "expand" the 8 characters to something which describes why the member is
there and what it does - and that's assuming there's even a choice of member
name.

There's a similar issue regarding a single member which can have many people
building it up and making changes but I've wittered on enough for now ...

Chris Mason

- Original Message - 
From: "Ed Gould" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Thursday, 16 February, 2006 9:09 PM
Subject: Re: Redirecting Software Functionality


> The other issue that I have seen in this that the copies of modules
> show up in a common library. It is close to impossible to pinpoint
> who put them there... Looking through SMF shows hundreds of updates
> and it gets worse as you don't know *WHEN* it happened. Unless you
> monitor the library on a daily basis it might be years before you run
> into the issue. If anyone knows of a way to stop it I would be happy
> to listen.
>
> Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Hal Merritt
SMF 30 records usually contain a program name. 

Do some chargeback. Hit 'em in the budget. 

One cool thing about this solution is that your customer base may deem
it enough of a business need to pay the freight.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ed Gould
Sent: Thursday, February 16, 2006 2:10 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Redirecting Software Functionality

On Feb 16, 2006, at 1:35 PM, Hal Merritt wrote:

> Don't forget our old friends in auditing. We are seeing these kinds of
> questions.
>
> I agree: it is a management issue. And audit trumps politics. More,  
> SOX
> holds that the managers of the folks that get sneaky can be held
> accountable.
>
> My $0.02.


The other issue that I have seen in this that the copies of modules  
show up in a common library. It is close to impossible to pinpoint  
who put them there... Looking through SMF shows hundreds of updates  
and it gets worse as you don't know *WHEN* it happened. Unless you  
monitor the library on a daily basis it might be years before you run  
into the issue. If anyone knows of a way to stop it I would be happy  
to listen.

Ed

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Shmuel Metz (Seymour J.)
In <[EMAIL PROTECTED]>, on 02/16/2006
   at 09:19 AM, David Andrews <[EMAIL PROTECTED]> said:

>Then take 'em to HR and have 'em shot. 

Why? Rope is reusable.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Ed Gould

On Feb 16, 2006, at 2:51 PM, Chris Mason wrote:


Ed,

When I was last on a long-term consultancy, by example, I tried to  
encourage
a crude approach to documenting responsibility - and purpose - in a  
common
library by creating a member $$$INDEX. Each line in this member  
started with
the name of each member I added - or had been added by someone I  
worked with
and I was changing - to be followed by my name and a brief  
explanation of
why it was there. (The "$" signs at the beginning of the name  
ensured that

the member appeared first in the member list of course.) This was a
technique I used to use simply to keep track of my own work with my
test/education systems since I was very likely to forget work done  
years
before. The 8-character member name was never much help as  
documentation. I
even had .$$$INDEX data sets in which I  
listed my

data sets with explanations.

I expect if you made this a rule and devised some code to highlight  
any
undocumented member at the end of each day/week, you might have a  
management
tool to help keep track of who did what and why especially when the  
"who"

was unavoidably detained incommunicado for whatever reason.



Chris,

BTDT but we are talking loadlibs here not text type files. Also the  
libraries where I have seen this done are common test load libraries.  
I won't *EVEN* go into finding LE modules in a production loadlib.


But you are correct this does work with sysprog libraries, Granted  
its hard to get others to go through this scenerio, but it is worth  
it. One vendor that I used to maintain their product had literally  
100's of members. For that one vendor only we maintained a separate  
loadlib pds.


In a well controlled environment it is usually doable. In others  
highly doubtful.


Trying to stop a smart programmer is difficult. I wish that the  
linkage editor would handle thing a bit differently but (to me) it is  
basic MVS flaw and will never be fixed.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Ed Gould

On Feb 16, 2006, at 3:35 PM, Hal Merritt wrote:


SMF 30 records usually contain a program name.

Do some chargeback. Hit 'em in the budget.

One cool thing about this solution is that your customer base may deem
it enough of a business need to pay the freight.



I have always been in environments with "funny" money. But that is an  
interesting possibility.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread tony babonas
I hasten to clarify, we restrict program usage, in our
case SAS, by restricting the load library from which it
is executed, for example our permission was written as
follows:

TSS PER( SASPROF ) DSN( HLQ.SAS.LOADLIB ) ACCESS(FETCH)
SYSID(ESYS) 

Since our search algorithm is "merge, all merge" users
of SASPROF can only execute load modules from this
file, via only 1 lpar.  Shops using "override, allover"
would be required to place SASPROF as the first profile
for each of its users.

Sorry for the initial misstatement.

tb 

-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of Stefan Finka
Sent: Thursday, February 16, 2006 4:49 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Redirecting Software Functionality

Hi Tony,
We also have CA-Top Secret (8.0)and I tried doing this
by protecting a PROGRAM resource by SYSID. However, I
found that CA removed this feature from TSS 5.1 onwards
for performance reasons. So, how exactly are you doing
this with TSS?
Thanks,
Stefan

---
---
For IBM-MAIN subscribe / signoff / archive access
instructions, send email to [EMAIL PROTECTED] with
the message: GET IBM-MAIN INFO Search the archives at
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-16 Thread Ed Gould

On Feb 16, 2006, at 10:07 PM, tony babonas wrote:


I hasten to clarify, we restrict program usage, in our
case SAS, by restricting the load library from which it
is executed, for example our permission was written as
follows:

TSS PER( SASPROF ) DSN( HLQ.SAS.LOADLIB ) ACCESS(FETCH)
SYSID(ESYS)

Since our search algorithm is "merge, all merge" users
of SASPROF can only execute load modules from this
file, via only 1 lpar.  Shops using "override, allover"
would be required to place SASPROF as the first profile
for each of its users.

Sorry for the initial misstatement.

tb




Tony,

I think SAS requires APF authorized library which you can control as  
well .


If someone copies "sasprof" to another library(and renames it)   
(along with any other modules) and the SAS program doesn't need (apf)  
authorization it is still wide open, no?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-17 Thread Joel C. Ewing

Ed Gould wrote:

On Feb 16, 2006, at 7:40 AM, Walt Farrell wrote:


On 2/15/2006 5:32 PM, Jerry Vernon wrote:
We are trying to restrict the execution of certain programs by LPAR 
so we
can just license them by processor.  The one in particular we are 
looking

at is COBOL. By limiting COBOL compiles to one Development LPAR.  Does
anyone know of any software that can be used to do this?


You can do this with the program control features of RACF.  Define the 
main COBOL compiler module to RACF in the PROGRAM class, with a 
universal access (UACC) of NONE, and then do a conditional permission 
based on the system ID.


Example:

RDEFINE PROGRAM program-name ADDMEM('load-library-name'//NOPADCHK) 
UACC(NONE)


PERMIT program-name CLASS(PROGRAM) ID(*) ACCESS(READ) 
WHEN(SYSID(allowed-smf-id))


If you're concerned about programmers making their own copy of the 
compiler modules via IEBCOPY, then you can also protect the library 
containing the compiler.



Walt,

BTDT... didn't work.. You have to allow read/exec to the steplib. Once 
you have given that out its wide open.


Ed

...
I haven't seen anyone mention only allowing RACF "EXECUTE" permission to 
the COBOL compiler loadlib and disallowing READ access.  That rules out 
casual IEBCOPY duplication of the library and renaming the compiler.  I 
think that should then insure that the SYSID-specific PROGRAM access is 
effective.



--
Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-17 Thread Ed Gould

On Feb 17, 2006, at 9:55 PM, Joel C. Ewing wrote:
SNIP-

I haven't seen anyone mention only allowing RACF "EXECUTE"  
permission to the COBOL compiler loadlib and disallowing READ  
access.  That rules out casual IEBCOPY duplication of the library  
and renaming the compiler.  I think that should then insure that  
the SYSID-specific PROGRAM access is effective.





Joel,

That may work for the compiler (will have to double check) but it  
still has issues with "coblib" (ie LE runtime & Subroutines). You  
*HAVE to give out read to that library for the binder.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-17 Thread tony babonas
Access level of fetch prevents reading, therefore copying.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Ed Gould
Sent: Thursday, February 16, 2006 10:18 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Redirecting Software Functionality

On Feb 16, 2006, at 10:07 PM, tony babonas wrote:

> I hasten to clarify, we restrict program usage, in our
> case SAS, by restricting the load library from which it
> is executed, for example our permission was written as
> follows:
>
> TSS PER( SASPROF ) DSN( HLQ.SAS.LOADLIB ) ACCESS(FETCH)
> SYSID(ESYS)
>
> Since our search algorithm is "merge, all merge" users
> of SASPROF can only execute load modules from this
> file, via only 1 lpar.  Shops using "override, allover"
> would be required to place SASPROF as the first profile
> for each of its users.
>
> Sorry for the initial misstatement.
>
> tb



Tony,

I think SAS requires APF authorized library which you can control as  
well .

If someone copies "sasprof" to another library(and renames it)   
(along with any other modules) and the SAS program doesn't need (apf)  
authorization it is still wide open, no?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-18 Thread Ted MacNEIL
>That may work for the compiler (will have to double check) but it  
still has issues with "coblib" (ie LE runtime & Subroutines). You  
*HAVE to give out read to that library for the binder.

Not any more, unless you're using an unsupported version of COBOL.
The latest releases don't support static links.

Even then, with the runtimes only you can't compile squat.


-
-teD

I’m an enthusiastic proselytiser of the universal panacea I believe in!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-20 Thread Chase, John
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Ed Gould
> 
> On Feb 17, 2006, at 9:55 PM, Joel C. Ewing wrote:
> SNIP-
> 
> > I haven't seen anyone mention only allowing RACF "EXECUTE"  
> > permission to the COBOL compiler loadlib and disallowing READ access.  
> > That rules out casual IEBCOPY duplication of the library and renaming 
> > the compiler.  I think that should then insure that the SYSID-specific 
> > PROGRAM access is effective.
> 
> That may work for the compiler (will have to double check) 
> but it still has issues with "coblib" (ie LE runtime & 
> Subroutines). You *HAVE to give out read to that library for 
> the binder.

So??  LE is no longer a "program product"; it's an integral part of z/OS.
Besides, LE doesn't compile anything.

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-20 Thread Ed Gould

On Feb 20, 2006, at 7:16 AM, Chase, John wrote:
- 
SNIP--




So??  LE is no longer a "program product"; it's an integral part of  
z/OS.

Besides, LE doesn't compile anything.



I wasn't just talking about compiling I was talking about linking and  
run time issues as well.
I guess I wasn't explaining fully (or if I did it was in an early  
entry) that I have found LE modules in a production library. Since  
everyone has read access to the coblib (for the linkage editor) its  
hard to put a stop to it.


Someone (sorry for got his name) said that with the new releases of  
the cobol compiler modules are no longer statically linked. I would  
guess though unless the binder execution specifies NCAL that syslib  
is still opened and there for read access has to be given. Even if  
you would take the coblib out of the concatenation the "other" user  
procs would have to be updated and that is no small feat when you  
have 500++ programmers scattered across several times zones. We were  
just barely able to talk to the local progs. Politics.


Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-20 Thread Chase, John
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Ed Gould
> 
> On Feb 20, 2006, at 7:16 AM, Chase, John wrote:
> >
> > So??  LE is no longer a "program product"; it's an integral part of 
> > z/OS.
> > Besides, LE doesn't compile anything.
> 
> I wasn't just talking about compiling I was talking about 
> linking and run time issues as well.

The original question was how to limit use of the COBOL *compiler* to a
specific system image.

> I guess I wasn't explaining fully (or if I did it was in an early  
> entry) that I have found LE modules in a production library. Since  
> everyone has read access to the coblib (for the linkage editor) its  
> hard to put a stop to it.

That's a different issue entirely.  The Binder (linkage editor) does not
need access to the *compiler* library.  Remember, too, that for *currently
supported* versions of COBOL, the "coblib" no longer exists.

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-20 Thread Ted MacNEIL
>Someone (sorry for got his name) said that with the new releases of  
the cobol compiler modules are no longer statically linked. 

That was me.

>I would  
guess though unless the binder execution specifies NCAL that syslib  
is still opened and there for read access has to be given.

LE/370 is not in SYSLIB. It's usually in LNKLST -- sometimes LPA.


>Even if  
you would take the coblib out of the concatenation the "other" user  
procs would have to be updated and that is no small feat when you  
have 500++ programmers scattered across several times zones. 

It's a complete replacement set of PROCs.
Also, our users do not have user compile PROCs, and if they run into problems 
we ensure that they are using the standard set.


>We were just barely able to talk to the local progs. Politics.

No management direction and procedures.
It fails and it's user written. Tough!

Because of the above, we got to ENTERPRISE COBOL 3.2 from MVS/COBOL 1.2.2 (if 
it had been a wine, it would have been vintage) with little fuss and two months 
time.

-
-teD

I’m an enthusiastic proselytiser of the universal panacea I believe in!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-20 Thread Ed Gould

On Feb 20, 2006, at 12:00 AM, Ted MacNEIL wrote:


Someone (sorry for got his name) said that with the new releases of

the cobol compiler modules are no longer statically linked.

That was me.


I would

guess though unless the binder execution specifies NCAL that syslib
is still opened and there for read access has to be given.

LE/370 is not in SYSLIB. It's usually in LNKLST -- sometimes LPA.


In every shop I have been the sys1.coblib (or make up your standard  
name the TSO link command if you used coblib insisted the name be  
sys1.coblib ) is always has been part of the syslib concatination .  
Try and get that out of user procs its pretty close to impossible.  
Like I said 100's of procs (or more) *BEFORE* the change for the  
binder (and linkage editor) almost always included it.


It may no longer be *NESC* but they procs are still out there. To  
deny they aren't will cause nasty grumblings and calls to the help  
desk and a ding or two against your next review. EVEN if published  
ahead of time It just "ain't"  worth the effort. It gets nasty  
especially when you take rolling IPL's to implement the change as a  
compile can and does run anyplace in the Jesplex.


Ed







Even if

you would take the coblib out of the concatenation the "other" user
procs would have to be updated and that is no small feat when you
have 500++ programmers scattered across several times zones.

It's a complete replacement set of PROCs.
Also, our users do not have user compile PROCs, and if they run  
into problems we ensure that they are using the standard set.




We were just barely able to talk to the local progs. Politics.


No management direction and procedures.
It fails and it's user written. Tough!

Because of the above, we got to ENTERPRISE COBOL 3.2 from MVS/COBOL  
1.2.2 (if it had been a wine, it would have been vintage) with  
little fuss and two months time.


-
-teD

I’m an enthusiastic proselytiser of the universal panacea I believe  
in!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: Redirecting Software Functionality

2006-02-20 Thread Ted MacNEIL
>Try and get that out of user procs its pretty close to impossible.  
Like I said 100's of procs (or more) *BEFORE* the change for the  
binder (and linkage editor) almost always included it.

LE is a different beast.
Enterprise/COBOL is a different beast.
If you used your old procs against it they would fail.
Period. End of statement.

>It may no longer be *NESC* but they procs are still out there. To  
deny they aren't will cause nasty grumblings and calls to the help  
desk and a ding or two against your next review. EVEN if published  
ahead of time It just "ain't"  worth the effort. 

It IS worth the effort.
It won't work the old way!
You have a choice:
Stay on the old (unsupported) COBOL.
Or:
Change.

The compiler can be read-protected.
LE is dynamically accessed.
SYS1.COBLIB is ignored, if included.

Saying this is not worth the effort is akin to saying that you will keep 
expanded storage around in 64-bit mode, even though it's not used.

IBM warned us that there would be changes when LE/370 was introduced in 1990, 
but we were the ones that asked for a common run-time across all languages.


-
-teD

I’m an enthusiastic proselytiser of the universal panacea I believe in!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html