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

[Dale Miller]

Dave Andrews responded to my post of 2012-03-02 relating the problems  
of Microsoft cloud software with the comment "Yes, but IBM should know  
better"
I agree that IBM should know better, but Microsoft should know better,  
as well. I related previously a problem with Windows file timestamps  
between DST and non-DST which Microsoft has refused to fix.


My heartburn with IBM is related to their inabililty to provide an  
external time standard facility for Z machines without an exhorbitant  
price. Since I am unable to keep up with the current market, I don't  
know what the current prices are, but when I was a gladiator in the Z- 
arena, we had serious difficulties with time differences between our Z  
machine and our 'NIX boxes which used an external time reference. Our  
management refused to acquire the IBM facility because of the $30k  
price. My Mac machine uses an external time reference without a $30K  
price tag. I can even get a wrist watch with an external time  
reference in the $100 price range.





Dale Miller

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

Re: SHARE in Atlanta -- Good Venue Choice!

[Ed Finnell]

Few years ago we were playing Miss. State at the Omni and went into  
overtime.
Couple of minutes in, the tornado sirens started going off and it actually  
trimmed the Omni. After a short delay, play resumed and the game was 
completed.  When the fans got to the parking lot...pretty nasty with broken 
glass 
and debris  everywhere. Still wonder about the overtime angel.
 
Don' forget spring ahead tonight in USA(and others)... 
 
 
In a message dated 3/10/2012 8:25:38 P.M. Central Standard Time,  
edja...@phoenixsoftware.com writes:

The Omni  Hotel at CNN Center in 
Atlanta is NICE! All SHARE guests get Select Guest  privileges and the 
price is 


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

Re: SHARE in Atlanta -- Good Venue Choice!

[Linda]

Hi Ed,

It's sure to be a great SHARE too. I hear that folks can still register on site 
for SHARE. www.share.org for the details. 

Have fun,

Linda

Sent from my iPhone

On Mar 10, 2012, at 6:21 PM, Edward Jaffe  wrote:

> So far, I commend SHARE on its choice of venue. The Omni Hotel at CNN Center 
> in Atlanta is NICE! All SHARE guests get Select Guest privileges and the 
> price is one of the lowest in recent memory. Good job, SHARE!
> 
> -- 
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> 310-338-0400 x318
> edja...@phoenixsoftware.com
> http://www.phoenixsoftware.com/
> 
> --
> 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

SHARE in Atlanta -- Good Venue Choice!

[Edward Jaffe]

So far, I commend SHARE on its choice of venue. The Omni Hotel at CNN Center in 
Atlanta is NICE! All SHARE guests get Select Guest privileges and the price is 
one of the lowest in recent memory. Good job, SHARE!


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

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

[John Gilmore]

In response to Chris Craddock's stricture about the disclosure of the
contents of fetch-protected storage Peter Relson wrote


This is not necessarily a violation of the IBM statement of integrity.
 It depends on whose data is being copied. I am allowed to put my own
non-sensitive data into fetch-protected storage and copy it to
non-fetch protected storage if I so choose. The requirement is that I
not allow the unauthorized user to access something he should not be
given access to. Fetch protection is just one tool in the bag of
tricks.  The owner of the data is typically the one that decides what
the access limitations are to be.


To borrow one of Chomsky's distinctions, this is true, but it is not
interesting.
I may of course do anything I like with something I myself put into
fetch-protected storage.  Moreover, I can know, locally and
procedurally, when I can do so; but most of the time I am dealing with
someone else's fetch-protected storage; and for it the only proper
rule is non-disclosure to the unauthorized.

An exact, entirely correct description of every action that
constitutes a breach of integrity at some time T may just be
achievable; but if it is achieved it will be obsolescent when it is
achieved; and it will resemble a contract drawn up by an attorney not
to inform but to protect a client from hostile litigation.  It will
not, that is, be at all helpful or even intelligible to any but the
already well-informed.

Integrity remains a crucial goal.  Practices that clearly put it at
risk must be avoided, and breaches must be closed as they are
detected.  (Disagreeable as this sounds, 1) we now learn chiefly from
these breaches; and 2) there will be more of them.)

ROTs simplify reality, and they thus always entail overkill, but they
are useful to people who lack the experience to make subtle
distinctions.

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: Backlevel IPCS issue at z/OS 1.13

[Timothy Sipples]

Just ask IBM first, officially, that's all.

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.

And yes, it's occasionally possible that a vendor's licensing terms and
conditions don't cover every "reasonable" use case. That's what
communication and clarification help solve.


Timothy Sipples
Resident Enterprise Architect (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.com

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

[Peter Relson]

I apologize in advance to Karl Schmitz if I have a bit of this
not quite exact.

>Perhaps some Integrity Vulnerability examples will help clarify:
>
>1)If your authorized program while executing in PSW key 0-7 stores 
>into an address provided by an unauthorized caller then this is a 
>violation of the IBM statement of integrity. 

The use of PSW key is imprecise. It's really "while not using the user's 
key, whether by that being the PSW key or by using MVCK/MVCDK/MVCSK/etc.".
But, more important, the (corrected) statement applies both to 
stores into and fetches from an address. Not just stores. Still, with
the exception that if the address has been validated to be a block
that the authorized program owns and that cannot change attributes while
mid-stream and that is known not to be fetch-protected, maybe. 
There are any number of cases where unauthorized "input" identifies a 
system-key system block (which is verified as being a system block) and 
that block gets updated as a result of a service call by the system 
running in system key.

>3)If your authorized program while executing in PSW Key 0-7 or 
>supervisor state returns control to an unauthorized requester in an 
>authorized state then this is a violation of the IBM statement of 
>Integrity. By authorized state I mean PSW Key 0-7, Supervisor state, or 
>now has the ability to MODESET. 

You really also need to add "unintended" if "unauthorized" refers only to
key, state, and APF. This is allowed as long as it is done 
correctly, which includes limiting it to only the 
intended requestor(s). Getting that correct is the difficult part. 
And of course that's at heart of this whole thread. Whether done by
a PC FLIH intercept returning via LPSW(E), or an SVC routine manipulating 
the RB,
or a stacking PC manipulating the linkage stack, the concept is the same.

>4)If your authorized program while executing in PSW Key 0-7 copies 
>fetch protected storage to non-fetch protected storage then this is a 
>violation of the IBM statement of integrity. 

This is not necessarily a violation of the IBM statement of integrity. 
It depends on whose data is being copied. I am allowed to put my own
non-sensitive data into fetch-protected storage and copy it to
non-fetch protected storage if I so choose. The requirement is that I not
allow the unauthorized user to access something he should not be given
access to. Fetch protection is just one tool in the bag of tricks.
The owner of the data is typically the one that decides what the access
limitations are to be.

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

Re: Backlevel IPCS issue at z/OS 1.13

[Peter Relson]

>> Q2) Am I wasting my time here. Should the latest version of IPCS work 
with all older dumps?
>> No, what you are trying to do is necessary. IPCS is not backwards 
compatible.
>Sure it is.

Not it isn't, if by "backwards compatible" in this case one means that 
"z/OS 1.13 IPCS can be relied upon to process successfully dumps from 
other releases". That cannot be relied upon. Of course on z/OS 1.13, via 
the MIGLIB approach, you can run a different release's IPCS in order to 
process that other release's dump.

AFAIK, the proper technique remains unchanged. If used on 1.11, it would 
work on 1.13.

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

Re: CICS Maintenance - LPA change

[Peter Relson]

If the owner of the service item did not tell you using dynamic LPA would 
work, you should have no expectation that it will, and you should not do 
it.

This applies to every piece of service regardless of product. 

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

Re: Interfacing with the MainFrame

[Ed Mackmahon]

Hi all.

Many thanks for your answers (At least the ones that were trying to help)

I am fully capable to develop and implement any solution I'll choose 

So scott if you don't mind I'll keep my bucks (-: , just want'ed to sense 

an interface direction from a few shops

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

[Clark Morris]

On 10 Mar 2012 00:51:45 -0800, in bit.listserv.ibm-main you wrote:

>Ron MacRae writes:
>>I've got a REXX exec that sets up an IPCS environment for z/OS levels
>>other than my current release With this REXX exec I can select a
>>version of IPCS modules/panels/ for every release of z/OS from 2.10
>>up to 1.13.
>
>Bearing in mind that I do not speak for IBM, I'd like to caution you on
>something here. It's one critically important distinction between what's
>technically possible and what's actually permissible, at least financially
>speaking.
>
>The "2.10" you mention is not z/OS, it's OS/390 (V2R10). That's a different
>product, also licensed.
>
>As background, when IBM introduced z/OS almost 12 years ago IBM also
>introduced sub-capacity licensing for z/OS and for practically all IBM
>software products for z/OS, including CICS, IMS, DB2, MQ, and many others.
>However, there are a very few prerequisites that customers are required to
>implement before enjoying sub-capacity licensing. One highly relevant and
>very well publicized requirement is that you must stop running all OS/390
>on your machine(s). That was (and is) part of the deal.
>
>OK, by now you see the potential problem. If you're running OS/390 V2R10's
>IPCS, you haven't stopped running OS/390 on your machine. Which means you
>wouldn't be eligible for sub-capacity licensing.

If I am using IPCS 2.10 under z/OS to read dumps submitted from
another location, am I running OS390?  I assume that modules compiled
and linked with system routines from that or prior eras don't violate
T&C.

Clark Morris 
>
>Be very, very careful here, folks. There are only a few simple rules.
>Follow them, please.
>
>
>Timothy Sipples
>Resident Enterprise Architect (Based in Singapore)
>E-Mail: timothy.sipp...@us.ibm.com
>

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

[Jim Mulder]

> OK, by now you see the potential problem. If you're running OS/390 
V2R10's
> IPCS, you haven't stopped running OS/390 on your machine. Which means 
you
> wouldn't be eligible for sub-capacity licensing.

  That is of course not correct.  IPCS (the dump viewing 
program for z/OS) is distributed in a special library 
(SYS1.MIGLIB) because it is intended that it can be run 
on various releases via a STEPLIB,TSOLIB/Tasklib.  Running
IPCS for OS/390 2.10 in this fashion on a supported release
of z/OS does not constitute "running OS/390 on your machine". 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

[Chris Mason]

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 why they made a particular suggestion, ...

IMNSHO this is an unacceptable approach. Even if they discuss RACF topics where 
we might hope that they are reliable, there should be reasonable explanations. 
However RACF would not be alone in exhibiting such a deficiency; the 
Communications Server product, which I know best if it wasn't obvious, can be 
found wanting in this regard also.

-

[1] One example of this I mention from time to time and have done so recently 
is the sample APPL statement for the secondary LUs managed by the SNA-oriented 
TELNET server provided in SEZAINST member VTAMLST. It is IMNSHO approximately 
half-right and so is approximately half wrong - and this is one side of the 
same product talking about the other side![1.1]

TCP1 APPL AUTH=NVPACE,EAS=1,PARSESS=NO,MODETAB=ISTINCLM,SESSLIM=YES

Wrong half:
The AUTH=NVPACE operand is utter, unmitigated rubbish!
The MODETAB=ISTINCLM operand is addlepated!

Right half:
The EAS=1 operand is obviously correct and saves 4K in comparison with the 
default EAS=509.
The SESSLIM=YES operand is obviously correct and has a rather complex role to 
play in some configurations as indicated by an APAR the text of which is no 
longer available.

Dubious (tending to wrong):
PARSESS=NO is pointless since it is a default for which PARSESS=YES is the 
override which adds function.

[1.1] Well, we must recognise that z/OS Communications Server originally was a 
product A, VTAM, and a product B, "TCP/IP for MVS" .

-

Chris Mason

On Sat, 10 Mar 2012 06:40:35 -0500, Robert S. Hansel (RSH) 
 wrote:

>Chris,
>
>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. In this particular case, it may have to do with options such as 
>the ability to specify clear text passwords with PRTCT= on VTAM APPL 
>definitions. 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.
>
>Regards, Bob

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

[Chris Mason]

There's no point in addressing Mr Metz since he does not read my posts. So to 
all interested polite subscribers

> > IBM suggests UACC(NONE) for them 

> Why?

If Mr Metz did read my posts, he would know that the "why" is not provided in 
Table 48, "UACC values for system data sets" in the z/OS Security Server RACF 
Security Administrator's Guide manual.

If, on the other hand, "why" applies to why Juan is asking the question, some 
hint of the answer may be provided in the initial post of the thread "Product 
libraries and UACC" in RACF-L posted last Thursday.

Chris Mason

On Fri, 9 Mar 2012 16:07:01 -0500, Shmuel Metz (Seymour J.) 
 wrote:

>In <1331312434.77887.yahoomailclas...@web125406.mail.ne1.yahoo.com>,
>on 03/09/2012
>   at 09:00 AM, Juan Mautalen  said:
>
>>We currently have our VTAMLST libraries protected with UACC(READ).
>>IBM suggests UACC(NONE) for them
>
>Why?
> ...

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

[Chris Mason]

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

[Chris Mason]

Juan

I have received a private communication in which it is pointed out that there 
*is* a potential reason why you might not want all and sundry[1] to be able to 
browse your VTAMLST partitioned data set.

In the spirit in which this note was sent, I will not divulge precisely what 
the potential security exposure is except that it is along the lines of what a 
disgruntled ex-employee might do in order to express his or her feelings over 
having been "let go". In the "hacker-friendly" world of today's communications, 
this would be described as a "denial of service" attack.

However, the proper solution to this mystery problem is not necessarily to bar 
all users of a z/OS system from being able to browse the VTAMLST partitioned 
data set, but to employ a SAF interface designed specifically to deal with the 
exposure, namely the VTAMAPPL class.[2]

>From the z/OS Communications Server SNA Network Implementation Guide manual:[3]



14.5.4 VTAM application security

You can specify a password on the APPL definition statement and require the 
application program to specify both its APPL definition statement name and its 
password when it opens its access method control block (ACB). The authority of 
the application program to gain access to the network can be verified by 
comparing the password in the OPEN ACB macroinstruction of the program to the 
password specified on the PRTCT operand of the APPL definition statement.

The VTAM application OPEN ACB security facility provides additional resource 
access control. To perform security processing, VTAM invokes a security 
management product (such as RACF) through the security authorization facility 
for any application program that is not APF-authorized. The security management 
product determines whether an application program access to the network is 
approved.

To enable the VTAM application OPEN ACB security facility, register the 
application program with a class of VTAMAPPL (CLASS=VTAMAPPL) in a security 
management product that is capable of controlling authorization for VTAM 
application program execution (such as RACF Version 1 Release 9). VTAM bypasses 
any password checking if the security management product provides the resource 
access control. The application program is authorized to access the network 
based on either the approval of the security management product or the 
user-specified password check.

...



http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b5b0/14.5.4

I would modify this text slightly as follows:

"The VTAM application OPEN ACB security facility provides additional resource 
access control."

changed to

"The VTAM application OPEN ACB security facility provides a much superior means 
to control the possibility successfully to open an VTAM ACB. It is recommended 
that this is used in preference to the PRTCT operand of the APPL definition 
statement which is, in effect, superseded by the this security facility. The 
PRTCT operand is preserved only to assist migration."

Development authors will not, of course, make such a change since they don't do 
"dogmatic"! However, it's the sort of text you might have found in a redbook 
covering the VTAMAPPL topic where clarity and honesty are more easily 
expressed.[4]

There is also another piece of text containing a couple of curiosities which I 
*think* are a legacy of poor wordsmithing when composed so that it has not 
stood the text of time:

"... in a security management product that is capable of controlling 
authorization for VTAM application program execution (such as RACF Version 1 
Release 9)."

A. It would surely be a poor "security management product" which had missed the 
opportunity to implement the VTAMAPPL class.

B. I managed to discover an on-line bookshelf for RACF V1R9.2 dating from 1993!

It is evident that, if you are serious about security as it applies to the 
definition of APPL statements in your VTAMLST partitioned data set, you will 
have invested in the VTAMAPPL class in conjunction with your chosen SAF product.

Apart from the concern, expressed in the days of SNI for which the 
"back-to-back" configuration was in part invented, that one enterprise with SNI 
connectivity to another enterprise should have no knowledge of the other 
enterprise's SNA configuration, I can't see any worry that what, in this day 
and age populated by "lemmings", is left of the VTAM definitions could be of 
any use, malicious or otherwise, to unauthorised eyes.

-

Just a clarification: it may be thought to be implied from my previous post 
that I was suggesting that, for a system programmer to maintain definitions in 
the VTAMLST partitioned data set, UACC(READ) sufficed. Of course minimally 
UACC(UPDATE) is obviously required for these particular legacy "masters of the 
universe"!

-

[1] If you are not familiar with some possibly confusing English-speaker idiom 
you find in posts, just use Google to resolve the mystery - and maybe expand 
your command of English

Re: A stupid idea? Using "twitter" like service for z/SO, et al., event notification.

[Chuck Arney]

John, I did that with a software product I previously authored.  The
Internet enabling product has an HTTP client interface that I used to
"tweet" as a demo.  Calls can be made from the product's REXX interface so
you could "tweet" from batch jobsteps or use an API to make requests from
program code.  So, it has been done!

Originally Twitter allowed the use of the HTTP authorization request header
so you could pass a base64 encoded user and password.  That was fairly easy
to do via HTTP requests.  Now Twitter requires authorization using the OAUTH
protocol which is much more involved from the client request side.  We found
the easiest thing to do for the oauth requirement was write a web service
running off platform, and use the product's web service client interface to
invoke the web service from z/OS instead of trying to do the oauth directly
from z/OS. 

It was an interesting facility because any number of people, worldwide, can
follow a single Twitter user and be notified about whatever topics you want
to publish to them.

Chuck Arney
Arney Computer Systems

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of McKown, John
Sent: Friday, March 09, 2012 10:30 AM
To: IBM-MAIN@bama.ua.edu
Subject: A stupid idea? Using "twitter" like service for z/SO, et al., event
notification.

I'll admit that my mind is not running quite right today. But something that
is bouncing around is notification of events happening on "servers",
especially z/OS. Would it be helpful, or stupid, to set up a "twitter" type,
secured, server. Then have the appropriate people from work, who have
smartphones or even PCs, be able to "follow" specific topics, which may be
things such as individual server names, or "z/OS product job status", or
"abended jobs". Or are some companies doing something similar using SMS? We
use SMS messages via CA-Unicenter for monitoring CA-Unicenter "tickets"
assigned to our group. But we cannot individually decide if we would like
more. And we don't generate tickets for things like "production job 
completed successfully on 2012-03-10 at 13:58" or "Event ... has not
completed successfully yet." On weekends, we are totally "dark" and the
on-call Production Support person must periodically logon to z/OS in order
to check statuses. I thought it might!
  be easier if they got "tweets" about things.

Of course, for all I know, this may be impossible due to software patents.

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

Re: TAPEMAP generator

[Farley, Peter x23353]

I am surprised that no one has yet recommended the TAPEMAP program in file 299 
(or 804 for the Jump-enhanced version) on the CBT site.  This will give you 
much, much more information or each file on a tape volume than a simple 
IEBGENER of the first label file.

You will still have the problem of geenrating the TAPEMAP JCL for each volume.  
Not having used the latest TAPEMAP version myself, I don't know if it might or 
might not have facilities to analyze multiple volumes with simpler JCL, but it 
is certainly worth your time to investigate.

HTH

Peter

> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of af dc
> Sent: Tuesday, March 06, 2012 11:03 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: TAPEMAP generator
>
> Hello,
> I need to do a tapemap for about 100 tapes (virtual volumes),
> I've jcl:
>
> //V1   EXEC PGM=IEBGENER
> //SYSPRINT DD SYSOUT=*
> //SYSOUT   DD SYSOUT=*
> //SYSUT1   DD DISP=OLD,
> //DSN=AL2999.SOMETH,
> //DCB=(RECFM=FB,LRECL=80,BLKSIZE=800,BUFNO=50),
> //UNIT=(VTS),LABEL=(1,BLP,EXPDT=98000),
> //VOL=SER=V1
>
> and I've volume list in format:
>
> V1
> V10001
> V10002
> ...
>
> what is the best way to generate 100 jcls ??? rexx ? icetool ?
> Many thx, A.Cecilio.
--

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

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

Re: VTAMLST - Who needs to read it

[Robert S. Hansel (RSH)]

Chris,

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. 
In this particular case, it may have to do with options such as the ability to 
specify clear text passwords with PRTCT= on VTAM APPL definitions. 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.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

-
2012 RACF Training
- Audit for Results   - Boston - APR 24-26
- Intro & Basic Admin - Boston - MAY 8-10
-

-Original Message-
Date:Fri, 9 Mar 2012 12:03:03 -0600
From:Chris Mason 
Subject: Re: VTAMLST - Who needs to read it

Juan

> IBM suggests UACC(NONE) for them (RACF Security Administrator Guide, apendix 
> D- Security for system datasets).

Why should the RACF developers be the arbiters of what is the correct access 
policy for VTAMLST? I would say that they were as likely to get such a proposal 
correct as any other development shop commenting on the products of another 
development shop. In other words, they are very, very likely to get it quite 
wrong - a phenomenon I have observed time and again!

Indeed, I have sometimes been very pleasantly surprised when a manual written 
by one development shop happened to come up with a clear explanation of how to 
use products from another development shop. Actually the only case I can 
remember over many years is GDDM talking about the 3270 data stream.

> (RACF Security Administrator Guide, apendix D- Security for system datasets)

Please - and this applies to all posters - provide an URL when referring to 
something state in a manual.
 
I suggest you post this query on the RACF-L list and challenge the gurus I 
notice there are not backward in coming forward and see if any of them can 
provide a reasoned argument why the following recommendation - which I dug out! 
- is present:



D.0 Appendix D. Security for system data sets

Table 48. UACC values for system data sets

Data set/UACC/Comments

...

SYS1.VTAMLST/NONE/

...



http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza7c0/D.0

Note that the people responsible for this table couldn't even imagine any 
justifying comment to add. I suspect they had wet fingers in the air!

If the RACF-L gurus cannot provide a reasoned argument, I suggest you treat 
this recommendation with the pinch of salt which in my opinion it deserves.

Remember "There is no substitute for understanding what you are doing.", a 
maxim that isn't necessarily ingrained on the conscience of IBM developers!

-

Anyhow the "users" who need to access VTAMLST are obviously the user of the 
VTAM/NET address space and any system programmer's TSO address space where the 
system programmer is responsible for maintaining the VTAMLST partitioned data 
set. I cannot see any reason why a user of the VTAM API would require access to 
VTAMLST for the reason that he/she was using the VTAM API.

-

Incidentally, while you are challenging the RACF-L gurus over access to 
VTAMLST, you might care equally to challenge them over the recommendation to 
specify universal access of READ for the VTAMLIB partitioned data set where, 
again, the comment field is completely absent in the now famous table. Again, I 
suspect a wet finger!

-

Moreover, take a look at the comments where the authors bothered to add 
comments and note whether there appear to have been any guidance other than 
common sense and - it must be said - note the considerable equivocation!

-

Chris Mason

On Fri, 9 Mar 2012 09:00:34 -0800, Juan Mautalen  
wrote:

>Hi:
>
>We currently have our VTAMLST libraries protected with UACC(READ). IBM 
>suggests UACC(NONE) for them (RACF Security Administrator Guide, apendix D- 
>Security for system datasets) . I want to make the change, but of course i 
>know i must be extremely carefull with this change. I need to detect all users 
>needing read access to VTAMLST. Human users are not my problem, my worry is 
>about non-human ones (users of system tasks, started tasks, etc.).
>
>What users need read access of VTAMLST?
>Does any userid associated with a VTAM application need to read VTAMLST?
>
>Thanks in advance for your help,
>
>Juan Mautalen

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

Re: Backlevel IPCS issue at z/OS 1.13

[Shane Ginnane]

On Sat, 10 Mar 2012 16:49:48 +0800, Timothy Sipples  wrote:

>If you're running OS/390 V2R10's
>IPCS, you haven't stopped running OS/390 on your machine. Which means you
>wouldn't be eligible for sub-capacity licensing.

Say what ???. How does running a module constitute "running OS/390" ?.
So IBM is coercing, nay *requiring*, (some of) its customers to break its 
(IBMs) licensing terms to support backlevel clients.
And IBM documents such.

Hmmm ... perhaps you'd better get your legal eagles to speak to the developers.
And then let the world at large know the outcome.

Shane ...

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

Re: A stupid idea? Using "twitter" like service for z/SO, et al., event notification.

[Timothy Sipples]

Not at all a stupid idea, John. There are many shops that already do that
sort of thing and many ways to do it.

As an aside, there are some organizations that handle "third shift" support
from some part of the world where/when it's first shift. That can be done
within the company itself (typically if it's a global multi-national sort
of company) or on a contract basis. That's been true for decades, and not
just in IT. To pick a random combination, between Los Angeles, Sydney, and
London you can have continuous support coverage, and it's never an
"unreasonable" hour of the night.


Timothy Sipples
Resident Enterprise Architect (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.com

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

Re: A stupid idea? Using "twitter" like service for z/SO, et al., event notification.

[Shane Ginnane]

On Fri, 9 Mar 2012 10:29:51 -0600, McKown, John  wrote:

>I'll admit that my mind is not running quite right today.

And how does that make today any different .  ;-)

I remember a time (not so long ago) when we were assured technology would free 
us from the shackles of our daytime desk.
Yeah, right. Like any of the cognoscenti believed that.

I must admit I have avoided joining the herd that stampeded to off to become 
twits. "Social media" seemed to imply being particularly sociable ...
One gripe I have with automated notification systems is that is a hell of a job 
to get *off* such a list. Especially if you are not an employee, but an 
itinerant that may get added to several such lists at different companies.

Shane ...

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

Re: Tips for continuing DD statement with only one parameter field

[Shmuel Metz (Seymour J.)]

In <0818533857960322.wa.paulgboulderaim@bama.ua.edu>, on
03/09/2012
   at 08:32 AM, Paul Gilmartin  said:

>How would that affect the syntax or semantics of the DD PATH=
>parameter?

A leading // would not be equivalent to a leading /.
 
-- 
 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: Backlevel IPCS issue at z/OS 1.13

[Shmuel Metz (Seymour J.)]

In <4631765647494587.wa.ronmacraehotmail.co...@bama.ua.edu>, on
03/09/2012
   at 05:48 AM, Ron MacRae  said:

>With this REXX exec I can select a version of IPCS
>modules/panels/

You seem to be missing the ...

>Q1) Any idea why "TSOLIB ACTIVATE DDNAME(IPCSLIBS)" appears to 
>work at z/OS 1.11 but not at 1.13?

What gives you the idea that it doesn't work at 1.13?

>Using ISRDDN while in IPCS I can see the the BLSG module is being
>loaded from ISPLLIB, which contains the 1.13 version.

Why doesn't it contain the older version up front?

>Adding a "LIBDEF ISPLLIB LIBRARY ID(IPCSLIBS) STACK" before the
>"ISPEXEC SELECT PGM(BLSG)" causes the older/correct version of BLSG
>to be loaded from IPCSLIBS but other modules appear to be 1.13
>versions.

Check what libraries they are in and where the 1.13 versions are
coming from[1], then fix your concatenations to put the old ones
first.

>Q2) Am I wasting my time here. Should the latest version of IPCS
>work with all older dumps?

>Q3) If the answer to 2) is no then how do other people do this?

They include all of the old libraries in front of the new ones.

[1] Probably MIGLIB.
 
-- 
 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: VTAMLST - Who needs to read it

[Shmuel Metz (Seymour J.)]

In <1331312434.77887.yahoomailclas...@web125406.mail.ne1.yahoo.com>,
on 03/09/2012
   at 09:00 AM, Juan Mautalen  said:

>We currently have our VTAMLST libraries protected with UACC(READ).
>IBM suggests UACC(NONE) for them

Why?

>Human users are not my problem,

Why not? Anybody who might be asked to diagnose a network issue
potentially needs access.
 
-- 
 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: Backlevel IPCS issue at z/OS 1.13

[Timothy Sipples]

Ron MacRae writes:
>I've got a REXX exec that sets up an IPCS environment for z/OS levels
>other than my current release With this REXX exec I can select a
>version of IPCS modules/panels/ for every release of z/OS from 2.10
>up to 1.13.

Bearing in mind that I do not speak for IBM, I'd like to caution you on
something here. It's one critically important distinction between what's
technically possible and what's actually permissible, at least financially
speaking.

The "2.10" you mention is not z/OS, it's OS/390 (V2R10). That's a different
product, also licensed.

As background, when IBM introduced z/OS almost 12 years ago IBM also
introduced sub-capacity licensing for z/OS and for practically all IBM
software products for z/OS, including CICS, IMS, DB2, MQ, and many others.
However, there are a very few prerequisites that customers are required to
implement before enjoying sub-capacity licensing. One highly relevant and
very well publicized requirement is that you must stop running all OS/390
on your machine(s). That was (and is) part of the deal.

OK, by now you see the potential problem. If you're running OS/390 V2R10's
IPCS, you haven't stopped running OS/390 on your machine. Which means you
wouldn't be eligible for sub-capacity licensing.

Be very, very careful here, folks. There are only a few simple rules.
Follow them, please.


Timothy Sipples
Resident Enterprise Architect (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.com

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