"NOTE: On October 31, 1995, IBM announced Year 2000 Support which stated
that, for any S/390 platform running MVS or OS/390 to be considered as Year
2000 Ready, all data sets must use Integrated Catalog Facility (ICF). It
will not be possible to access data via a VSAM Catalog or CVOL when the
sys
Point of curiosity: does anybody remember when they removed CVOL
support?
It was part of Y2K. I think it officially died on 1/1/2000 but there
may have been a PTF that killed it shortly before that.
--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
pe
In <[EMAIL PROTECTED]>, on 03/01/2006
at 08:08 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>Likewise so for z/OS data set name qualifiers. And there it's an
>artificial and senseless limitation, persisting only because of
>inertia.
Point of curiosity: does anybody remember when they removed
In a recent note, Leonard Woren said:
> Date: Wed, 1 Mar 2006 11:25:37 -0800
>
> On Wed, Mar 01, 2006 at 01:04:31PM -0500, Walt Farrell ([log in to unmask])
> wrote
> :
> > >> "Eight character tokenization is Mickey Mouse" - suggested for SHARE
> > >> in Anaheim.
> > >>
> > > Likewise so
On 3/1/2006 2:18 PM, Leonard Woren wrote:
On Wed, Mar 01, 2006 at 01:04:31PM -0500, Walt Farrell ([EMAIL PROTECTED])
wrote:
...snipped...
Let's distinguish between "huge number of affected programs" and
"huge amount of code that would need to be rewritten."
OK.
A subset of the affected I
>Now all the vendors including IBM change their "huge" number of
> programs by *deleting* all of their dsname checking code, replacing it
> with a simple call to the system subroutine. Duh, this is the way it
> should have been done from day 0.
Yes! But!
Can you say testing?
Can you identify all
"Leonard Woren" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> On Wed, Mar 01, 2006 at 01:04:31PM -0500, Walt Farrell
([EMAIL PROTECTED]) wrote:
> > Possibly inertia, but more likely because of the huge amount of code
> > that would need to be rewritten in both IBM and vendor p
On Wed, Mar 01, 2006 at 01:04:31PM -0500, Walt Farrell ([EMAIL PROTECTED])
wrote:
> >> "Eight character tokenization is Mickey Mouse" - suggested for SHARE
> >> in Anaheim.
> >>
> > Likewise so for z/OS data set name qualifiers. And there it's
> > an artificial and senseless limitation, persistin
On 3/1/2006 10:28 AM, [EMAIL PROTECTED] wrote:
In a recent note, "Shmuel Metz (Seymour J.)" said:
Date: Wed, 1 Mar 2006 09:53:30 -0500
"Eight character tokenization is Mickey Mouse" - suggested for SHARE
in Anaheim.
Likewise so for z/OS data set name qualifiers. And there it's
an ar
>True, but not much consolation to the guy who got fired when I showed
management one of his, er, impolite (ok, unprintable) dsnames.
What idiot!
If you don't want it to be read, don't write it.
If you don't want it to be heard, don't say it.
Somebody puts unprintable stuff out in the work domai
CMS had a "cute" way for dataset name hiding - any file with a type of zero
was not visible on a read only link.
Of course, a simple DDR COPY to a TDISK and viola.
--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should yo
In a recent note, "Shmuel Metz (Seymour J.)" said:
> Date: Wed, 1 Mar 2006 09:53:30 -0500
>
> "Eight character tokenization is Mickey Mouse" - suggested for SHARE
> in Anaheim.
>
Likewise so for z/OS data set name qualifiers. And there it's
an artificial and senseless limitation, persis
In <[EMAIL PROTECTED]>, on 02/28/2006
at 10:48 PM, Leonard Woren <[EMAIL PROTECTED]> said:
>Edward E. Jaffe wrote:
>> That's why "God" invented VM.
>Huh? I thought it was the devil... ;-)
Perhaps the Devil invented clumsy monitor system and vowel movement,
but REXX and XEDIT are both positi
Walt Farrell wrote:
> In a more normal shop, I personally don't see much of an exposure.
True, but not much consolation to the guy who got fired when I showed
management one of his, er, impolite (ok, unprintable) dsnames. :-)
I think I ran into it while investigating a full vtoc, which turned
ou
On Tue, 2006-02-28 at 10:21 -0800, Edward E. Jaffe wrote:
> But, in this case, I'm afraid the potential
> resource consumption increases of MLS might be more like strapping an
> extra 100 Lb (45.359 Kg) pack on your back! Tough choice
Depending on your naming conventions and willingness to cut s
Craddock, Chris wrote:
It would be folly to depend on information hiding as the only security
strategy, especially as the feature has only lately been grafted on and
is (ahem) less than bullet proof. But at the same time, adding another
layer of Kevlar to the vest may look like a fine idea if you
In <[EMAIL PROTECTED]>, on 02/26/2006
at 06:49 PM, Thomas Berg <[EMAIL PROTECTED]> said:
>I must say that I don't understand You both.
That says more about you than about us ;-)
>If You don't want to support the code then don't.
And that avoids the interruptions how? And what happens if mana
> If you could smell the gases, it meant your oxygen mask was not on
> properly and you would be well advised to deal with it quickly.
>
> This smells the same to me. If someone can convince a "privileged"
> product into giving them information they cannot get on their own,
then
> there is a se
When I went through altitude chamber training, the instructor expalined that as
external pressure decrease, gases in the body would try to expand. As internal
pressure grew, they would exit the body any way they could. If you could smell
the gases, it meant your oxygen mask was not on properly
Paul Hanrahan wrote:
I'm getting out of the business if I can. Though I did love it. Cole's essay
on programming was terrific. - Paul Hanrahan
Looks like I may be getting out of the business because
I must. I still love it, but I can't seem to find enough
work to keep paying the bills: "our mai
== McKown, John == wrote2006-02-27 00:10:
I must say that I don't understand You both.
If You don't want to support the code then don't.
Are You too afraid to say that to the whiners ? ;-)
No, I'm not afraid to tell the whiners to "go roll a hoop". However, in
addition to the w
: IBM-MAIN@BAMA.UA.EDU
Subject: Code borrowing (was RE: Data Set Name "Hiding")
I wish I had all you guys' problems. We have no one
here who understands basic JCL, let alone any compiled
or interpreted language. I'd gladly giv e away
everything I have developed over the years, eve
d have achieved it in 6th grade.
Old and cynical,
tb
-Original Message-
From: IBM Mainframe Discussion List
[mailto:[EMAIL PROTECTED] On Behalf Of McKown, John
Sent: Sunday, February 26, 2006 5:11 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Data Set Name "Hiding"
> -
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Berg
> Sent: Sunday, February 26, 2006 11:50 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Data Set Name "Hiding"
>
>
> I must say that I don&
I must say that I don't understand You both.
If You don't want to support the code then don't.
Are You too afraid to say that to the whiners ? ;-)
I have always seen source hiding in circumstances like this as silly and sneaky.
I never do this.
Thomas Berg
== Shmuel Metz (Seymour J.) ===
In <[EMAIL PROTECTED]>,
on 02/23/2006
at 08:56 PM, "McKown, John" <[EMAIL PROTECTED]> said:
>That may come across as arrogant on my part. But I've been burned too
>many times by "smart" programmer who "borrow" code from me, without
>asking, then enter problem reports against it when the code do
>What does 1.4 to 1.6 have to do with performance management interfacing
with security?
I read in a previous post that the dsn hiding feature because available
with 1.5. Management and performance folks around here want to remain very
aware of all processes which might effect cpu usage. Mr. Far
On Thu, 23 Feb 2006 14:13:29 -0800, Edward E. Jaffe
<[EMAIL PROTECTED]> wrote:
>Mark Zelden wrote:
>> You can't expect to have a separate LPAR for every small client
>> in all service-bureau environments. Too expensive, too much overhead.
>>
>
>That's why "God" invented VM.
>
That still would no
On 2/23/2006 5:07 PM, [EMAIL PROTECTED] wrote:
We are in the process of upgrading from 1.4 to 1.6 and I just put my
performance management folks on the alert for this in case the data
security folks would come asking.
Whether name-hiding would pose any problems depends on many factors,
includi
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL
> Sent: Wednesday, February 22, 2006 6:00 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Data Set Name "Hiding"
>
>
> >His response was
>You can't expect to have a separate LPAR for every small client
in all service-bureau environments. Too expensive, too much overhead.
I disagree.
Especially, with the unnatural acts you guys have to perform due to SOX.
We never set up multiple customers on the same LPAR at IGS, Canada.
Our Canad
>We are in the process of upgrading from 1.4 to 1.6 and I just put my
performance management folks on the alert for this in case the data
security folks would come asking.
As you 'Mercans say: "Huh?"
Or, as we Canajuns say: "Eh?"
I don't understand this statement at all.
What does 1.4 to 1.6 hav
>The typical concern is that an unprivileged user may be able to persuade
a privileged user (e.g. some STC) to access data the unprivileged user
was not otherwise entitled to and/or to disclose that data to some third
party.
Now we're getting into the deliberate (read: malicious), rather than acci
Mark Zelden wrote:
You can't expect to have a separate LPAR for every small client
in all service-bureau environments. Too expensive, too much overhead.
That's why "God" invented VM.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
On Thu, 23 Feb 2006 00:00:00 GMT, Ted MacNEIL
<[EMAIL PROTECTED]> wrote:
>>> In other cases, it may be a real confidentiality concern. For example,
>> in a service-bureau setting, data set names may contain customer names
>> or acronyms.
>
>That does not make sense at all!
>It's not best practice
>If he has to troll to find tools to do his job, how do we know he knows
how to do his job.
I'd go further... do we know he knows what is job is!
We are in the process of upgrading from 1.4 to 1.6 and I just put my
performance management folks on the alert for this in case the data
security folks
>> In other cases, it may be a real confidentiality concern. For example,
> in a service-bureau setting, data set names may contain customer names
> or acronyms.
That does not make sense at all!
It's not best practice to have different customers on the same LPAR, or sharing
the same UCATs!
So
>His response was along the lines of "well, how do I know that's
true if I can't see inside every PDS? There might be something there
that I could use if I knew it existed."
Wrong statement/question.
Rather, he should be asking: "Do you have 'x', which I need to do my job."
If he has to troll to
>
> Just curious. How much of an exposure exists if a user knows the name
of
> a data set [s]he can't open?
>
The typical concern is that an unprivileged user may be able to persuade
a privileged user (e.g. some STC) to access data the unprivileged user
was not otherwise entitled to and/or to di
One fellow who worked here many moons ago had a file named something along the
lines of "SYSXXX.AUDITORS.PLEASE.DONT.LOOK." I think it was just a backup of
something else he was working with, but it was still amusing.
Jon
Fortunately, naming MVS datasets is so ugly, that very little
inform
Gilbert Saint-Flour wrote:
On Thursday 23 February 2006 10:24, Edward E. Jaffe wrote:
Just curious. How much of an exposure exists if a user knows
the name of a data set [s]he can't open?
In certain environments, it may just be "security through obscurity".
In other cases, it may be
Gilbert Saint-Flour wrote:
On Thursday 23 February 2006 10:24, Edward E. Jaffe wrote:
Just curious. How much of an exposure exists if a user knows
the name of a data set [s]he can't open?
In certain environments, it may just be "security through obscurity".
In other cases, it may be a re
On Thursday 23 February 2006 10:24, Edward E. Jaffe wrote:
> Just curious. How much of an exposure exists if a user knows
> the name of a data set [s]he can't open?
In certain environments, it may just be "security through obscurity".
In other cases, it may be a real confidentiality concern. F
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Thomen
> Sent: Thursday, February 23, 2006 10:20 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Data Set Name "Hiding"
>
>
>
> If you don&#x
Sounds like a conspiracy to slow the MF down ;- )
Mark Thomen <[EMAIL PROTECTED]>
Sent by: IBM Mainframe Discussion List
02/23/2006 11:19 AM
Please respond to
IBM Mainframe Discussion List
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
Re: Data Set Name "Hiding"
"
On 2/23/2006 10:53 AM, John P Kalinich wrote:
Ken wrote:
Not that I want to add overhead but does anyone know if Top Secret has
the same facility?
I believe that it is DFSMS making the RACROUTE AUTH calls, so Top Secret or
ACF2 should be able to process them.
Top Secret or ACF2 should be ab
On 2/23/2006 10:24 AM, Edward E. Jaffe wrote:
Just curious. How much of an exposure exists if a user knows the name of
a data set [s]he can't open?
In the context for which we developed that support (some of the
highly-classified government installations) the exposure is considered
signific
"Jim Marshall" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> My Security folks are eager to have us implement something called
"Dataset
> Name Hiding". This will hide dataset names from a user's view if they do
> not have the necessary security authority for these files. I am n
Ken wrote:
>Not that I want to add overhead but does anyone know if Top Secret has
>the same facility?
I believe that it is DFSMS making the RACROUTE AUTH calls, so Top Secret or
ACF2 should be able to process them.
Regards,
John Kalinich
Computer Sciences Corp
--
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Edward E. Jaffe
Sent: Thursday, February 23, 2006 9:24 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: Data Set Name "Hiding"
Just curious. How much of an exposure exists if a user knows the
Not that I want to add overhead but does anyone know if Top Secret has
the same facility?
-Original Message-
Jim Marshall wrote:
> My Security folks are eager to have us implement something called
> "Dataset Name Hiding". This will hide dataset names from a user's view
> if they do not
Jim Marshall wrote:
My Security folks are eager to have us implement something called "Dataset
Name Hiding". This will hide dataset names from a user's view if they do
not have the necessary security authority for these files. I am not sure of
all the details as to what RACF permissions are neede
On 2/23/2006 6:59 AM, Jim Marshall wrote:
My Security folks are eager to have us implement something called "Dataset
Name Hiding". This will hide dataset names from a user's view if they do
not have the necessary security authority for these files. I am not sure of
all the details as to what RACF
On Thu, 23 Feb 2006 05:59:26 -0600 Jim Marshall <[EMAIL PROTECTED]> wrote:
:>My Security folks are eager to have us implement something called "Dataset
:>Name Hiding". This will hide dataset names from a user's view if they do
:>not have the necessary security authority for these files. I am not s
My Security folks are eager to have us implement something called "Dataset
Name Hiding". This will hide dataset names from a user's view if they do
not have the necessary security authority for these files. I am not sure of
all the details as to what RACF permissions are needed "to see" a file.
Ha
55 matches
Mail list logo
