Thank you all . It looks like security policies will have to be revisited .
I'll go back to the management and see if they are okay to get rid off this
requirement . As others have pointed out , JESJOBS and OPERCMDS would be the
way to go if they insist on keeping these rules .
I am also
In before Martin chimes in with his treasure trove -
https://mainframeperformancetopics.com/
- KB
‐‐‐ Original Message ‐‐‐
On Wednesday, May 6, 2020 10:41 PM, Barkow, Eileen
<02bc504b1642-dmarc-requ...@listserv.ua.edu> wrote:
> https://developer.ibm.com/ seems to have some useful
However you are specifying a device, or your task is selecting the device, the
device is either already allocated to something else, or it is boxed and has no
I/O paths.I'm not a big VM guy, but is it possible you have a device
defined to multiple guests, and you have it online to more
On Wed, 6 May 2020 22:14:40 -0500, Tim Hare wrote:
>... they boil down to authenticating using some non-RACF method, ...
>
Ouch!
Sounds as if RACF needs an RFE, if true.
But what does ssh do, for example?
-- gil
--
For
As many have stated you are limited to 8 upper case characters, 7 if you still
use UADS; however if the MQ user is off-platform, perhaps one of the various
tools for mapping other IDs to a RACF ID could be used? These are all part of
RACF (not sure about ACF2 or Top Secret) but as I see it
Actually, it's an MVS and JES question; the issues would be the same if you
were using, e.g., ACF2.
Entering system commands in the jobstream is an obsolete technique dating back
to OS/360 and entering JES commands in the jobstream is an obsolete technique
dating back to HASP and ASP. In most
As near as I can tell, the system as delivered uses the OPER resource of the
TSOAUTH class only to control access to the OPERATOR command. If you want to
control the ability to issue JES commands from batch without an exit, you will
need to update the access list for other classes and
On Wed, 6 May 2020 16:58:59 -0400, David Spiegel wrote:
>+1
+1
>
>On 2020-05-06 16:43, Frank Swarbrick wrote:
>> Are you still wanting to limit "non OPER" users to only those jobs beginning
>> with their user ID? If so, for gods sake why? Sounds very 1960s...
>>
And how do you prevent their
Thank you for all your patience with me.
Getting zOSMF up is a challenge at best in a MONOPLEX. In a SYSPLEX it is a
bit of a terror. I had use ISH to chain thru OMVS and find the bbgzangl
executable. Then modify the PATHS in the ANG1 and the SRV1 after more research
than I care to
Hi Lizette,
But , the JOBCLASS profiles looks to be protecting only the class parameter
within the JCL . We are looking for something that enforce the jobname to start
with their userid
Regards,
Robert
--
For IBM-MAIN
Maybe this?
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ic
ha700/ControllingJobClassUsage.htm
Controlling job class usage
An installation can control job class usage by granting access based on the
submitter's profile, or based on the owner's profile, or both.
The
Hi Lizette ,
Yes...we run JES2 and SDSF both
Regards,
Robert
From: IBM Mainframe Discussion List on behalf of
Lizette Koehler
Sent: Thursday, May 7, 2020 2:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO/E SUBMIT exit
Do you run JES2? Do you have SDSF?
Hi Lizette ,
Yes . We run JES2 and SDSF both
Regards,
Robert
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
+1
On 2020-05-06 16:43, Frank Swarbrick wrote:
Are you still wanting to limit "non OPER" users to only those jobs beginning
with their user ID? If so, for gods sake why? Sounds very 1960s...
From: IBM Mainframe Discussion List on behalf of Robert
Hahne
Do you run JES2? Do you have SDSF? Do you have z/OSEM?
Any tools?
Lizette
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Robert Hahne
Sent: Wednesday, May 6, 2020 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TSO/E SUBMIT exit
Hello listers ,
I understand
I agree ..It is a pretty old system and these exits have been out there for
very long and we might get rid off that restriction some time soon .
But , I wanted to eliminate this exit first and was wondering if RACF can do
that .
Are you still wanting to limit "non OPER" users to only those jobs beginning
with their user ID? If so, for gods sake why? Sounds very 1960s...
From: IBM Mainframe Discussion List on behalf of
Robert Hahne
Sent: Wednesday, May 6, 2020 2:34 PM
To:
Hello listers ,
I understand this is a RACF question . But thought someone can help me here .
We have a requirement where TSO submit exit IKJEFF10 needs to be eliminated .
Currently it is written to ensure only those users with TSOAUTH(OPER) are
allowed to submit jobs with any name . Rest of
90% of 40 is 36, so I would make it 70 on one system then try starting
z/OS 2.2. Once you see the utilization there you can figure another
size and change again.
On Wed, May 6, 2020 at 1:34 PM Elaine Beal wrote:
>
> Thanks.
> I can't start 2.2 (so can't enter the $DACTIVATE) and on my 1.13
> I guess you're not using "bare / }green screen" 3270 emulation
ObForeverAmber AFAIK the 3178 was IBM's last green screen. Even then you had
fields that you could click on with a detector pen; later 3270 models added
additional facilities.
> ( ISPF) to access your mainframe?
ISPF, CICS,
On 5/6/20, Bob Bridges wrote:
> Ok, stupid question: What's a swapbar? It sounds familiar, so maybe it's
> something I'm familiar with but have just forgotten momentarily. But...?
I guess you're not using "bare / }green screen" 3270 emulation (
ISPF) to access your mainframe?
Is anybody
Thanks.
I can't start 2.2 (so can't enter the $DACTIVATE) and on my 1.13 system
it's 40 cyls, 90% free so presumably CFSIZER would say that's enough.
I can double or triple it no problem but I find it a little strange that 2.2
needs
over 90% of my current allocation when JOBS/JOES/BERTS etc
On Thu, 7 May 2020 01:02:55 +0800, David Crayford wrote:
>>
>> On 2020-05-06 11:32 PM, Kirk Wolf wrote:
>>> Not so fast: cp and cat are both /bin/sh built-in commands ( documented
>>> under "Built-in commands" in the command reference for sh). So the shell
>>> does employ DDs;-)
>>
>> I didn't
https://developer.ibm.com/ seems to have some useful things like tutorials,
but I cannot find any forums for reporting problems and answering questions.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
scott Ford
Sent: Wednesday, May 6, 2020 1:04 PM
To:
Cheryl,
Amen, I agree. The Developerworks information is valuable for all.
IBM must stop, who do we need to write to ?
Scott
On Wed, May 6, 2020 at 12:49 PM Cheryl Watson
wrote:
> Hi all,
>
> Remember when IBM went through and deleted from their websites what they
> considered "old" manuals
On 2020-05-07 12:55 AM, David Crayford wrote:
On 2020-05-06 11:32 PM, Kirk Wolf wrote:
Not so fast: cp and cat are both /bin/sh built-in commands ( documented
under "Built-in commands" in the command reference for sh). So the shell
does employ DDs;-)
I didn't know that! I thought they were
On 2020-05-06 11:32 PM, Kirk Wolf wrote:
Not so fast: cp and cat are both /bin/sh built-in commands ( documented
under "Built-in commands" in the command reference for sh).So the shell
does employ DDs;-)
I didn't know that! I thought they were binaries in /bin! Thanks ;)
Hi all,
Remember when IBM went through and deleted from their websites what they
considered "old" manuals and documentation? Well, they just did it again!
They've removed all the DeveloperWorks articles that have provided such
excellent information since its creation. And these aren't just OLD
*optional* might be debatedI wouldn’t run without.
In a sysplex configuration, the alternate sysplex root file system is a hot
standby for the sysplex root file system that is used to replace the current
sysplex root file system when the sysplex root file system becomes unowned. The
In case the sysplex root becomes corrupt. It will save you from losing your
entire sysplex. The directory structure of the ALTROOT must be the same as
the sysplex root. I run this script on a regular basis. I don't claim that it
is the most efficient or best way to do, but it does get the
Thank you
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Allan Staller
Sent: Wednesday, May 6, 2020 11:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ALTROOT
This is for recovery and migration purpose. It will allow the sysplex
This is for recovery and migration purpose. It will allow the sysplex root
dataset to be replaced without a sysplex-wide IPL.
It is optional and *NOT* required.
HTH,
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Steve Beaver
Sent: Wednesday, May 6, 2020 11:27 AM
I concur/Lizette. CFSIZER will give you a size. Double that and make the large
enough so that you never have to worry.
Mine are 120 cyls to support 100K jobs and 300k JOES.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Lizette Koehler
Sent: Wednesday, May 6, 2020
I have come up against a question that I can't answer.
In OMVS why is an ALTROOT needed in a SYSPLEX?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message:
I did an edit to [[Core dump]] in Wikipedia, in which I mentioned SAR and IPCS.
Does anybody remember which release added unformatted dumps? The first release
of IPCS. Transaction dumps.
Also, if anybody has the relevant manuals please consider adding references to
the article. Thanks.
--
I would start with the CFSIZER tool on www.ibm.com - not great, but it would be
a good starting point.
Next use $DACTIVATE on you V2.2 system. See what it says. The ability to
upgrade is not as important as how many BERTs you need or what the checkpoint
size needs to be.
Then if you have
Allan,
Thank you.
How would I know how large to make it, leaving a reasonable amount of free
space?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
On Wed, May 6, 2020 at 9:35 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> >On 2020-05-06 8:31 PM, Kirk Wolf wrote:
> >> cat DD: isn't documented as supported? :-)
> >>
> >> what about "cp //DD:xxx /dev/fd1" - is that the shell?
> >>
> I don't believe shell is
Hi
As Ed points out Userids, Passwords and Passphrases are the easiest security
credentials to bypass; by malware, sharing credentials, looking over ones
shoulder or even the odd post-it note! And your users should definitely not be
using the same password for all of your disparate systems, but
On Mon, 4 May 2020 16:29:48 -0400, Tony Harminc wrote:
>On Mon, 4 May 2020 at 04:23, Barbara Nitz wrote:
>
>> Doesn't matter. With an IMS region, you cannot use cancel (z/OS:
>> "non-cancelable, use force arm"). You cannot use force arm (z/OS: "cancel
>> first, please"). And you cannot use
On Wed, 6 May 2020 20:40:20 +0800, David Crayford wrote:
>We've had this conversation many times before. Utilities that use
>fopen() support DD:xxx and are not likely to change.
>
>Gil is being pedantic. But maybe IBM should update the doc?
>
Pedantic, yes, but I'd be loath to use in code
FYI.. IBM announces the beta release of SDK for Python – z/OS.
If you are interested in participating in this feedback program, please email
Jennifer Rowan (jen...@ca.ibm.com), Offering Manager for IBM SDK for Python –
z/OS, and she will add you to the program.
For comments or feedback
> If there's a complaint about something I wrote, OK, fine, but how about
making sure it's a complaint about something I wrote? :-)
You wrote several things. Different responses referred to different things you
wrote. I don't recall anybody claiming that you can't have a long userid in
instream
SWAPBAR A toggle command used to display or remove a list of
point-and-shoot fields for each ISPF logical screen. These
fields are displayed on the last line of the physical
screen. The SWAPBAR / command displays a a pop-up window
which
Ok, stupid question: What's a swapbar? It sounds familiar, so maybe it's
something I'm familiar with but have just forgotten momentarily. But...?
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* The only thing UFO aliens deserve is to be ignored...and when we finally
develop the
David,
- using bash interactively and /bin/sh otherwise seems like a reasonable
approach.
(this makes me consider whether the COZBATCH default - to run the user's
login shell - is problematic if this were popular)
- I agree that change bash to use spawn looks extremely hard.
Also, since bash
We've had this conversation many times before. Utilities that use
fopen() support DD:xxx and are not likely to change.
Gil is being pedantic. But maybe IBM should update the doc?
On 2020-05-06 8:31 PM, Kirk Wolf wrote:
cat DD: isn't documented as supported? :-)
what about "cp //DD:xxx
cat DD: isn't documented as supported? :-)
what about "cp //DD:xxx /dev/fd1" - is that the shell?
On Tue, May 5, 2020 at 3:50 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Tue, 5 May 2020 13:12:44 -0500, Kirk Wolf wrote:
> >
> >"deploy" ?
> >
> "employ"?
>
>
On 2020-05-02 8:24 AM, Wayne Bickerdike wrote:
As a Yorkshireman, it means "anything ". Nowt means "nothing".
Ha ha ha ha - very good!
For this sort of stuff I like to look at the swap reason code.
TI - TSO input wait
TO - TSO output wait (3-asterisk syndrome?)
US - unilateral swap
EX -
BTW, if you want to use the delete key in the bash command line you need
to put the following line into your readline init file.
echo "\"\e[3~\"": delete-char >> ~/.inputrc
On 2020-05-05 8:11 PM, Michael Babcock wrote:
After reading this thread I finally have my command line completion back!
Agreed. I've got access to she source repository and I don't think spawn
will ever be implemented.
I use bash as a login shell and /bin/sh for scripting and batch. Best of
both worlds.
On 2020-05-05 9:56 PM, Kirk Wolf wrote:
FWIW, I would love to use bash exclusively on z/OS, but without
51 matches
Mail list logo
