Doug Fuerst writes:
All I can say is I have 4.1 or 550 for z/OS and there is not one shred
of USS support in the product that I can find. I was told that if I
wanted that support I needed Omegamon for USS. So if this is the case,
even the support people and the marketing people are unaware of it.
I'll echo a previous poster, it's not bad. It also has some room to
get better and I expect Norm and others are working hard to that end. CA
has improved a great deal in recent years :) And hired some of the
cream of the crop.
-Original Message-
From: IBM Mainframe Discussion List
I will be out of the office starting 02/22/2008 and will not return until
03/10/2008.
SHARE: 2/23-23, Vac 2/29-3/9, Returning 3/10. I will be watching Notes
and S/T as time permits at SHARE.
--
For IBM-MAIN subscribe /
Interesting article on the z10 with the quote, an integrated hardware decimal
floating-point processor to aid with financial and enterprise resource planning
applications. I hope there will be sessions at SHARE in Orlando expanding on
the z10 announcement. The article is here:
Assuming that the z10 will be using the new z6 CPU you can get some
information about the z6 CPU from:
www2.hursley.ibm.com/decimal/IBM-z6-mainframe-microprocessor-Webb.pdf
This was released last Oct.
Don Higgins wrote:
Interesting article on the z10 with the quote, an integrated hardware
On Fri, 22 Feb 2008 17:16:10 -0500, Dave Barry [EMAIL PROTECTED] wrote:
I believe shared ISPF profile is the case. This behavior started in
z/OS 1.8 with the advent of the SDSF address space.
Thanks for the tip about using SYSID with no operands.
The SDSF server address space has been around
On Fri, 22 Feb 2008 14:43:03 -0600, David Eisenberg
[EMAIL PROTECTED] wrote:
Another way is to issue a RACROUTE REQUEST=EXTRACT
LOG=NONE
Am I correct when I say that both of these solutions require APF-authorization
(or similar)? Might there be a way that would not require this?
Yes, all the
On 23 Feb 2008 08:07:34 -0800, in bit.listserv.ibm-main
(Message-ID:[EMAIL PROTECTED])
[EMAIL PROTECTED] (Walt Farrell) wrote:
I wouldn't have thought that there would be a security
issue with merely
interrogating an authorization level, but perhaps I'm
wrong...
One could argue that
---snip-
My advice in another message about letting the system do the checking
still stands.
---unsnip
I strongly agree.
Consider that a potential customer may WANT all the logging he can get,
possibly weeding out
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at
I'm sorry about this.
I typed a long message to post, and the next thing I know, an empty message was
sent.
-
Too busy driving to stop for gas!
-Original Message-
From: Ted MacNEIL [EMAIL PROTECTED]
Date: Sat, 23 Feb 2008 21:15:17
To:IBM-MAIN@BAMA.UA.EDU
Subject: Re:
I have argued for many years that charge-back should *not* include CPU seconds
or any other resource measure. Charge back by service. $.50 per transaction.
$.20 per policy. $500 per bed per month.
I have been making the same argument since 1981.
Users should be charged on something
On Fri, Feb 22, 2008 at 11:37 AM, in message
[EMAIL PROTECTED],
Lizette Koehler [EMAIL PROTECTED] wrote:
Just thought you would like to know that I was reading the zJournal mag
(hardcopy) and noticed an article called
Basic BASH scripting for Mainframe System Programmers
by Mark Post
In [EMAIL PROTECTED], on
02/22/2008
at 11:17 AM, Jon Brock [EMAIL PROTECTED] said:
It is not possible to start an ssh session from within OMVS under TSO.
Do you mean that the code does not support it, or only that there are
configuration issues that prevent it? What is the specific obstacle
IBM's port of ssh has code that detects an OMVS environment and explicitly
prohibits execution. Same thing for the sftp command, as it uses 'ssh'
under the covers.
Try either one and you get:
FOTS1252 The SSH client cannot be run under OMVS.
FOTS0841 Connection closed
Its a big secret as to
For your own userid, you can use LISTDSD or RLIST to check resource
authorization without cutting audit records.
That would be perfect... is LISTDSD something I can do from within an
assembler program? Or is there an assembler macro equivalent?
All I really need to do is, from within an
All I really need to do is, from within an assembler application, invoke some
function that will tell me whether or not the current userid is authorized via
a
given RACF profile to *read* a resource. The userid will always be either the
person who is logged onto TSO or is the submitter of a
You can call IRRSEQ00 (R_Admin) services within an assembler program to
issue RACF commands like LISTDSD and RLIST and you don't need to be APFed
for what you want to do. No audit records are cut and no messages to syslog
for violations.
The command results are sent back into a buffer that you
18 matches
Mail list logo
