Re: VTAMLST - Who needs to read it

2012-03-11 Thread Alan Watthey
Chris,

I think you'll find Netview uses ATCCONxx just like VTAM does for deciding
what is initially active at startup.  However, CNMCONxx is for specifying
any additional members that you want Netview to include in STATMON and that
are not in ATCCONxx.  Perhaps one doesn't activate much at all in ATCCONxx
and then one gets automation to activate what one wants depending upon
certain criteria.  CNMCONxx would then specify all the VTAM major nodes that
might get activated.

Back to the original question, most sites I have worked at have the VTAMLST
concatenation in Netview so that members can be browsed from it without
having to resort to TSO.

Regards,
Alan.

> This is the NetView STATMON component pre-processor program. Just as
> VTAM has its ATCCONxx member which provides the names of members as
> dreamed up by the responsible system programmer so the NetView STATMON
> component pre-processor program has its CNMCONxx member providing a
> similar service.

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


Host on Demand Installation

2012-03-11 Thread Jake anderson
Hi,

Are there any specific minimum MSU  requirement for installing HOD ?  Since
Our environment is capped at 13 MSU and 21 MSU wth no ZAAP and ZIIP
facility.

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


Re: VTAMLST - Who needs to read it

2012-03-11 Thread Mark Douglas (CITEC)
Once you have interpreted which member(s) within VTAMLST are required by 
address spaces other than NET, you can always split them into a separate 
dataset and concatenate it under the VTAMLST DD. Then grant only the minimal 
access required to each VTAMLST dataset. We used to do this to separate access 
for the network support people vs VTAM sys progs. 

Cheers,
MARK DOUGLAS 

* Disclaimer *

The contents of this electronic message and any attachments are intended only 
for the addressee and may contain privileged or confidential information. They 
may only be used for the purposes for which they were supplied. If you are not 
the addressee, you are notified that any transmission, distribution, 
downloading, printing or photocopying of the contents of this message or 
attachments is strictly prohibited. The privilege of confidentiality attached 
to this message and attachments is not waived, lost or destroyed by reason of 
mistaken delivery to you. If you receive this message in error please notify 
the sender by return e-mail or telephone.

Please note: the Department of Public Works carries out automatic software 
scanning, filtering and blocking of E-mails and attachments (including emails 
of a personal nature) for detection of viruses, malicious code, SPAM, 
executable programs or content it deems unacceptable. All reasonable 
precautions will be taken to respect the privacy of individuals in accordance 
with the Information Privacy Act 2009 (Qld). Personal information will only be 
used for official purposes, e.g. monitoring Departmental Personnel's compliance 
with Departmental Policies. Personal information will not be divulged or 
disclosed to others, unless authorised or required by Departmental Policy 
and/or law.

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


Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-11 Thread John Gilmore
Swans, white and black, have a long history in scholastic and then
mathematical logic, figuring too frequently in illustrations of modus
ponens:

All swans are white.  A is a swan.  Ergo, A is white.

The heavy, unquestioning use of this scheme presumably reflects the
fact that northern hemisphere swans, European and Japanese swans in
particular, were/are white.

All this changed when the southern hemisphere, Australian and New
Zealand, black swan, Cygnus atratus, was discovered in the late 18th
century.

"Black swan" then came to have another, quite different connotation.
It is used to describe putatively rare things when they are in fact
found and sometimes even to derogate rareness, as in the recent heavy
use of variants of

Unscrupulous, greedy bankers are not black swans.

Produce is used in logic as shorthand for provide an instance of in
the sense of the existential quantifier, assert or show there is at
least one S such that S is an x.

Obtusely, I had not thought about the 'production of a black swan' in
its other, literal or Marxist economic sense, accomplished say by
painting a white swan black; but I agree that the idea is repellent.
(We again have a significant, growing population of white swan pairs
resident throughout the year in our glacial ponds/reservoirs here in
Massachusetts west of Boston.  They are very tolerant of people, and I
should not want to see that change.)

John Gilmore, Ashland, MA 01721 - USA

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


Re: Aprapros of Nothing

2012-03-11 Thread Ulrich Krueger
Just tell Outlook to _not_ mark emails from IBM-MAIN@bama.ua.edu as Spam.


Regards,
Ulrich Krueger


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Andy Coburn
Sent: Sunday, March 11, 2012 2:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Aprapros of Nothing

Not due to anything I've overtly done, Microsoft Outlook 2003 has decided
that any e-mail with the subject "Re: Program FLIH backdoor - This is a
criminal breach of security!" is to be placed immediately in the Junk E-mail
folder. And does so.

Does Outlook know something I don't know?

Andy  

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

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


Mistyped: Meant Apropros of Nothing

2012-03-11 Thread Andy Coburn
Finger check. Sorry.

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


Aprapros of Nothing

2012-03-11 Thread Andy Coburn
Not due to anything I've overtly done, Microsoft Outlook 2003 has decided
that any e-mail with the subject "Re: Program FLIH backdoor - This is a
criminal breach of security!" is to be placed immediately in the Junk E-mail
folder. And does so.

Does Outlook know something I don't know?

Andy  

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


Re: Backlevel IPCS issue at z/OS 1.13

2012-03-11 Thread Shmuel Metz (Seymour J.)
In
,
on 03/11/2012
   at 08:37 AM, Timothy Sipples  said:

>I did not post my (unofficial) thoughts as merely an academic,
>theoretical exercise. In particular, I'm aware of one customer that
>grabbed Language Environment from OS/390, ran it on z/OS, and...
>well, that wasn't (isn't) free.

Never mind free; it isn't supported even if you're paying for both.
 
-- 
 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...@bama.ua.edu with the message: INFO IBM-MAIN


Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-11 Thread Gerhard Postpischil

On 3/11/2012 9:07 AM, John Gilmore wrote:

There is a long intellectual tradition which has it that the
production of just one black swan is an unanswerable refutation of the
proposition that all swans are white.


I cringe at the word "production" - purportedly (google search 
came up empty) not too long ago in our nation's history it was 
common practice to paint sparrows for the purpose of selling 
them as parakeets.


While I don't recall a proposition on swans, I was reminded of 
the Pejorative Calculus (Joel Cohen, "On The Nature Of 
Mathematical Proofs", The Worm-Runner's Digest, Vol. III, No.3, 
December 1961), where Lemma I (all horses are the same color) is 
credited to Professor Lee M. Sonneborn, then at U. of Kansas.


Gerhard Postpischil
Bradford, VT

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


Re: VHow convert "historic" STCK to local time?

2012-03-11 Thread Ed Finnell
I think I paid $39 for a Casio Wave-ceptor two years ago. Keeps good time,  
DST has Auto, ON, and Off. Auto doesn't work. So have to set it when the 
hurdles  move.
 
 
In a message dated 3/11/2012 2:10:38 A.M. Central Daylight Time,  
dalelmil...@comcast.net writes:

I can  even get a wrist watch with an external time  
reference in the $100  price range.



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


Re: VTAMLST - Who needs to read it

2012-03-11 Thread Lizette Koehler
Chris,

I have reviewed my JCL for TPX and it has an allocation for the SYS1.VTAMLST
in it.  How or why it is in the STC JCL, I am unclear.

But thanks for checking further.

Lizette

> 
> Lizette
> 
> After posting I realised that I had an example - other than VTAM - of a
program which
> needs to read members of VTAMLST partitioned data sets. This is the
NetView
> STATMON component pre-processor program. Just as VTAM has its ATCCONxx
> member which provides the names of members as dreamed up by the
responsible
> system programmer so the NetView STATMON component pre-processor program
has
> its CNMCONxx member providing a similar service.
> 
> Knowing that proposing that a program might need access to VTAMLST based
on a
> vague feeling that it sort-of might was just wrong, I was forced to
realise that knowing
> the member names was the key. The NetView STATMON component pre-processor
> program is the proof!
> 
> Thus, if a program requires that you provide it with a list of member
names, you can
> safely say that it requires access to VTAMLST partitioned data sets.
> 
> Chris Mason
> 
> On Sat, 10 Mar 2012 12:19:19 -0600, Chris Mason 
> wrote:
> 
> >Lizette
> >
> >> I can say that ..., TPX, ... might need READ access.
> >
> >What evidence do you have that TPX actually needs to "read" members of
the
> VTAMLST partitioned data set? Are you obliged to provide the major node
names, that
> is, the actual member names? If not TPX - or any other program - would be
"all at
> sea" when faced with the requirement to read the members - or I guess such
a
> program could "read" the directory and make guesses based on the names it
found ...
> >
> >Alternatively, a program like TPX could have "programmed operator access"
and
> discover the member names that way. However I wonder what information,
additional
> to what is can be derived from the messages in reply to a DISPLAY command,
might
> be needed.
> >
> >> I can say that ... a few other things might need READ access.
> >
> >Would you be so kind as to divulge the "other things" and apply the same
test as I
> just outlined for TPX?
> >
> >> I know as a sysproc, I ...
> >
> >While I'm here, I can't resist mentioning that I would tend to look for a
"sysproc" in a
> partitioned data set rather than sitting in a chair in front of a screen
editing one!
> >
> >Chris Mason
> >
> >On Fri, 9 Mar 2012 13:05:42 -0500, Lizette Koehler

> wrote:
> >
> >>...
> >>I can say that VTAM, TPX, and a few other things might need READ access.
I know
> as a sysproc, I would need UPDATE authority to make changes.
> >>
> >>Lizette

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


TAPEMAP execution for multiple tapes

2012-03-11 Thread Sam Golob

Hi Folks,

   Here is a way that I TAPEMAP multiple tapes, with a PROC.

   All the best...

Sam

//*
//*   TAPEMAP UTILITY PROGRAM
//*
//TAPEMAP PROC VL=XX
//TAPEMAP EXEC PGM=TAPEMAP
//STEPLIB  DD DISP=SHR,DSN=SYS2.LINKLIB
//SYSUT1   DD DISP=OLD,
// UNIT=562,
// VOL=(,RETAIN,SER=&VL),
// LABEL=(,BLP,EXPDT=98000)
//SYSPRINT DD SYSOUT=*
//SYSPRNT2 DD SYSOUT=*
//  PEND
//*
//S01 EXEC TAPEMAP,VL=EXS001
//S02 EXEC TAPEMAP,VL=EXS002
//S03 EXEC TAPEMAP,VL=EXS003
//S04 EXEC TAPEMAP,VL=EXS004
//S05 EXEC TAPEMAP,VL=EXS005

* * *

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


TAPEMAP generator

2012-03-11 Thread Sam Golob

Hi Folks,

   To TAPEMAP a bunch of volumes, I use a PROC.  Then, to specify the 
volume list, all you have to do is have the volser as the one PROC 
variable, and it is just a list of 100 PROC executions.


   All the best...

Sam Golob

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


Re: VTAMLST - Who needs to read it

2012-03-11 Thread Chris Mason
Lizette

After posting I realised that I had an example - other than VTAM - of a program 
which needs to read members of VTAMLST partitioned data sets. This is the 
NetView STATMON component pre-processor program. Just as VTAM has its ATCCONxx 
member which provides the names of members as dreamed up by the responsible 
system programmer so the NetView STATMON component pre-processor program has 
its CNMCONxx member providing a similar service.

Knowing that proposing that a program might need access to VTAMLST based on a 
vague feeling that it sort-of might was just wrong, I was forced to realise 
that knowing the member names was the key. The NetView STATMON component 
pre-processor program is the proof!

Thus, if a program requires that you provide it with a list of member names, 
you can safely say that it requires access to VTAMLST partitioned data sets.

Chris Mason

On Sat, 10 Mar 2012 12:19:19 -0600, Chris Mason  wrote:

>Lizette
>
>> I can say that ..., TPX, ... might need READ access.
>
>What evidence do you have that TPX actually needs to "read" members of the 
>VTAMLST partitioned data set? Are you obliged to provide the major node names, 
>that is, the actual member names? If not TPX - or any other program - would be 
>"all at sea" when faced with the requirement to read the members - or I guess 
>such a program could "read" the directory and make guesses based on the names 
>it found ...
>
>Alternatively, a program like TPX could have "programmed operator access" and 
>discover the member names that way. However I wonder what information, 
>additional to what is can be derived from the messages in reply to a DISPLAY 
>command, might be needed.
>
>> I can say that ... a few other things might need READ access.
>
>Would you be so kind as to divulge the "other things" and apply the same test 
>as I just outlined for TPX?
>
>> I know as a sysproc, I ...
>
>While I'm here, I can't resist mentioning that I would tend to look for a 
>"sysproc" in a partitioned data set rather than sitting in a chair in front of 
>a screen editing one!
>
>Chris Mason
>
>On Fri, 9 Mar 2012 13:05:42 -0500, Lizette Koehler  
>wrote:
>
>>...
>>I can say that VTAM, TPX, and a few other things might need READ access.  I 
>>know as a sysproc, I would need UPDATE authority to make changes.
>>
>>Lizette

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


Re: VTAMLST - Who needs to read it

2012-03-11 Thread Chris Mason
Bob

There are a couple of points I missed from my previous post.

-

A. It was implied but I should have said that I would trust any advice 
regarding access to data sets *only* from a publication originating from the 
development authors of the product involved. Obvious really.

I did check the manuals of the SNA component (VTAM) of z/OS Communications 
Server using likely keywords but I found no general recommendations. Thus it 
would appear that the VTAM folk are just relying on product knowledge and 
common sense in order for a system programmer to decide access requirements.

So this leads to some advice for Juan:

Juan

In the thread you initiated last August in the RACF-L list regarding the 
VTAMAPPL class, you said you didn't know a great deal about VTAM. Well, it 
would seem that the person to whom you should turn first is the VTAM specialist 
in your installation for advice on anything to do with VTAM. Then he or she can 
post - probably the best place being the IBMTCP-L list[1] - for any additional 
help.

I have, of course, always to assume that in any installation where VTAM is used 
in earnest - not necessarily in conjunction with "business-critical" activity 
but close to it - there is such a specialist. Unfortunately I have heard of 
installations with holes in their feet!

-

B. In my footnote criticising the supplied VTAMLST sample member of SEZAINST, I 
forgot to mention the operand which should feature but doesn't. This is the 
REGISTER operand. With this in mind the "rightness" percentage drops well under 
50% and the "wrongness" percentage rises correspondingly.

It is very likely these days that installations are relying on APPN in order, 
first and long ago, to escape the tyranny of PATH statements and, secondly, in 
order to support Enterprise Extender. With APPN enabled, it is a complete waste 
of time to have the name of any activated APPL statement - I am assuming sense 
has prevailed (no thanks to the SEZAINST VTAMLST member) and a *model* APPL 
statement is in use - representing a TELNET client which always causes the SNA 
session to be *initiated*, such as applies to a "display" connection/session, 
registered in the APPN directory system. Thus, for a "display" model APPL 
statement REGISTER=NO should be present.

Sensible sample:

 VBUILD TYPE=APPL
TD*  APPL  EAS=1,REGISTER=NO,SESSLIM=YES

For any activated APPL statement representing a TELNET client which relies upon 
the primary LU application to initiate the SNA session such as applies to a 
"printer" connection/session, the opposite applies and such a potential session 
end-point needs to be registered in the APPN directory system. Thus, for a 
"printer" model APPL statement REGISTER=CDSERVR should be present - or, note 
well, assumed by default!

 VBUILD TYPE=APPL
TP*  APPL  EAS=1,REGISTER=CDSERVR,SESSLIM=YES

-

[1] For IBMTCP-L subscribe / signoff / archive access instructions, send email 
to lists...@vm.marist.edu with the message: INFO IBMTCP-L

-

Chris Mason

On Sat, 10 Mar 2012 12:23:58 -0600, Chris Mason  wrote:

>Bob
>
>Please see the post which adds to my initial post in this thread.
>
>> When IBM suggests UACC(NONE) for a system dataset, this is usually an 
>> indicator the dataset contains security control information that should be 
>> kept secret.
>
>If you rely on the VTAMAPPL class for proper security, VTAMLST partitioned 
>data sets don't - with the possible exception of the means to reconstruct 
>configuration information of a business rival which no longer applies in these 
>post-SNI days - see my earlier post.
>
>> In this particular case, it may ...
>
>I'm not interested in "may" but precisely what. System programmers should not 
>have to be dealing with "Smoke and mirrors"!
>
>> ... such as the ability to specify clear text passwords with PRTCT= on VTAM 
>> APPL definitions.
>
>I'm also not interested in "such as" but "precisely as".
>
>Taking the case of PRTCT, this was what passed (playing with words!) for 
>security in the mid-1970s and - rather a joke - development described it as 
>being a "password". So very obviously the VTAMAPPL class knocks spots off the 
>PRTCT operand.
>
>Do you have any VTAM features in mind other than PRTCT or was "such as" an 
>application of the "mushroom" principle?
>
>> Whereas the RACF team at IBM may not always provide detailed information 
>> about why they made a particular suggestion, I have always found them to be 
>> very thoughtful and never arbitrary.
>
>That Table 48, "UACC values for system data sets" in the z/OS Security Server 
>RACF Security Administrator's Guide manual falls foul of the principle that 
>you cannot - a priori - take what product A says about product B as 
>reliable.[1] I will accept they are not arbitrary and demonstrate thought when 
>they justify their pontifications and indicate what their wise thoughts 
>actually were!
>
>> Whereas the RACF team at IBM may not always provide detailed information 
>> about 

Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-11 Thread John Gilmore
Since this sort of thing is expected of me, I will note that we find
ourselves between Scylla and Charybdis here.

Chris Craddock's formulation was open to the exception that Peter
Relson took: there is fetch-protected storage the contents of which
its owner is entirely free to make available to others.

Peter's exception is logically impeccable.  It did, however, seem to
me to be a very special one; and I observed that it was.  I still
prefer the ROT that the contents of protected storage should not be
made available to the unauthorized (in any but very special
circumstances, when they are known procedurally to be innocuous.).

To repeat myself now, Peter is nonetheless correct in the abstract.
There is a long intellectual tradition which has it that the
production of just one black swan is an unanswerable refutation of the
proposition that all swans are white.

John Gilmore, Ashland, MA 01721 - USA

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


Re: Program FLIH backdoor - This is a criminal breach of security!

2012-03-11 Thread Peter Relson
>this is true, but it is not interesting.
(with respect to my pointing out some flaws in the examples)

I respectfully disagree.

When something is presented as a guideline or even perhaps a "rule of 
thumb", that is one thing.
When something is presented as a rule, that is a different thing.

If it is stated that "x is true" when it is not, that ought to be 
challenged.
I believe that that is where the examples fell.

Peter Relson
z/OS Core Technology Design

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