On Thu, 7 Mar 2019 19:33:31 +, Seymour J Metz wrote:
>My understanding is that he needs ISPF services in his application.
Then he is probably not going to be able to get it to run, safely and with
integrity, under TSO/E. It will need a multi-address space implementation
unless he's very lu
On Thu, 7 Mar 2019 15:45:14 +0200, Steff Gladstone
wrote:
>But if I TSOEXEC CALL the Cobol I/O routine, will it retain the context
>between calls? Won't the DCBs and ACBs and working storage be reinitialized
>on every call?
You need to TSOEXEC CALL the main COBOL program. It must run isolated,
@LISTSERV.UA.EDU
Subject: Re: RACF: Limiting update-authorization of a file to a particular
application
On Wed, 6 Mar 2019 19:29:05 +0200, Steff Gladstone
wrote:
>One further question:
>
>Would use of IKJEFTSI/IKJEFTSR/IKJEFTST work here? I.e., provide an
>isolated eenvironment for RACF while
But if I TSOEXEC CALL the Cobol I/O routine, will it retain the context
between calls? Won't the DCBs and ACBs and working storage be reinitialized
on every call?
בתאריך יום ה׳, 7 במרץ 2019, 02:34, מאת Walt Farrell :
> On Wed, 6 Mar 2019 19:29:05 +0200, Steff Gladstone <
> steff.gladst...@gmail.
On Wed, 6 Mar 2019 17:26:56 +, Seymour J Metz wrote:
>ATTACH by an unprivileged application cannot change the authority and
>privileges of the address space. TSOEXEC passes the request to the Terminal
>Monitor
>Program (TMP), which sets the unauthorized tasks nondispatchable before
>attac
On Wed, 6 Mar 2019 19:29:05 +0200, Steff Gladstone
wrote:
>One further question:
>
>Would use of IKJEFTSI/IKJEFTSR/IKJEFTST work here? I.e., provide an
>isolated eenvironment for RACF while maintaining continuity within the I/O
>routine without re-initializing its working storage on each call?
On Wed, 6 Mar 2019 19:01:25 +0200, Steff Gladstone
wrote:
>
>This works ok for privileged users (i.e., the subtasking and I/O logic
>works fine, the COBOL I/O routine is not reintiaiized on each call, and of
>course there are no RACF issues). But for non-privileged users RACF issues
>the follo
On Wed, 6 Mar 2019 19:01:25 +0200, Steff Gladstone
wrote:
>
>The COBOL I/O routine is called by a fairly complex TSO/ISPF application.
>So we decided to communicate to the I/O routine via a subtask in order to
>simplify the environment (as per Walt Farrell's claim that a new TCB
>creates a paral
From: IBM Mainframe Discussion List on behalf of
Steff Gladstone
Sent: Wednesday, March 6, 2019 12:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF: Limiting update-authorization of a file to a particular
application
One further question:
Would use of IKJEFTSI/IKJEFTSR/IKJEFTST
, 2019 12:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF: Limiting update-authorization of a file to a particular
application
Although we have progressed with creating an program-controlled
environment, we are still experiencing problems in this area.
We have a COBOL routine whose purpose is
One further question:
Would use of IKJEFTSI/IKJEFTSR/IKJEFTST work here? I.e., provide an
isolated eenvironment for RACF while maintaining continuity within the I/O
routine without re-initializing its working storage on each call?
On Wed, 6 Mar 2019 at 19:01, Steff Gladstone
wrote:
> Although
Although we have progressed with creating an program-controlled
environment, we are still experiencing problems in this area.
We have a COBOL routine whose purpose is to open a VSAM data set on the
first call, perform I/O (read and write) on subsequent calls, and finally
close the dataset on the f
On Thu, 21 Feb 2019 15:22:33 +, Seymour J Metz wrote:
>AFAIK it won't reset the dirty bit. It does isolate AC(0) from AC(1).
Yes, it will, for that isolated parallel environment.
--
Walt
--
For IBM-MAIN subscribe / signof
On Wed, 20 Feb 2019 15:51:23 +0200, Steff Gladstone
wrote:
>Do I understand correctly that TSOEXEC CALL creates a new subtask
>environment which is "insulated" from the goings-on in the mother task?
Yes. The parallel environment established by TSO/E via TSOEXEC would be clean,
even if the orig
-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF: Limiting update-authorization of a file to a particular
application
Do I understand correctly that TSOEXEC CALL creates a new subtask
environment which is "insulated" from the goings-on in the mother task?
Would specifying TASKLIB further ensure
Using the term "RACF-authorized" is incorrect in this context. All
modules loaded in the address space must be program-controlled (not
authorized), which means they must be covered by a PROGRAM profile that
includes a group member for the dataset from which they were loaded.
The fact that a mo
Do I understand correctly that TSOEXEC CALL creates a new subtask
environment which is "insulated" from the goings-on in the mother task?
Would specifying TASKLIB further ensure that only those modules
loaded/linked/attached from the TASKLIB library need be RACF-authorized?
Or is there something I
: RACF: Limiting update-authorization of a file to a particular
application
And I forgot to mention, in addition to statically allocated STEPLIB,
for TSO/ISPF I believe you also need to include static ISPLLIB allocations.
Joel C Ewing
On 2/18/19 11:37 AM, Seymour J Metz wrote:
> PADS was
st on behalf of
> Joel C. Ewing
> Sent: Sunday, February 17, 2019 5:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [SPAM] Re: RACF: Limiting update-authorization of a file to a
> particular application
>
> Unless things have changed, in order for RACF program-controlled
From: IBM Mainframe Discussion List on behalf of
Joel C. Ewing
Sent: Sunday, February 17, 2019 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [SPAM] Re: RACF: Limiting update-authorization of a file to a
particular application
Unless things have changed, in order for RACF program
http://mason.gmu.edu/~smetz3
>>
>>
>> From: IBM Mainframe Discussion List on behalf
>> of Steff Gladstone
>> Sent: Thursday, February 7, 2019 6:37 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: RACF: Limiting update-author
On Sun, 17 Feb 2019 18:05:59 +0200, Steff Gladstone
wrote:
>Ok. We have been playing around with program control.If PROG1 (a COBOL
>program incidentally) is to be allowed exclusively to update file MY.FILE,
>then we:
>
>1. introduced PROG1 into the list of programs in AUTHPGM in member IKJEF
Discussion List on behalf of
Steff Gladstone
Sent: Sunday, February 17, 2019 11:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF: Limiting update-authorization of a file to a particular
application
Ok. We have been playing around with program control.If PROG1 (a COBOL
program incidentally) is
gt;
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List on behalf
> of Steff Gladstone
> Sent: Thursday, February 7, 2019 6:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RACF: Li
-authorization of a file to a
particular application
On 2/7/19 5:57 AM, Elardus Engelbrecht wrote:
> Steff Gladstone wrote:
>
> Please consider subscribing to RACF-L at
> http://listserv.uga.edu/archives/racf-l.html
>
>
>> We have an TSO application for end-users that allow
On 2/7/19 5:57 AM, Elardus Engelbrecht wrote:
> Steff Gladstone wrote:
>
> Please consider subscribing to RACF-L at
> http://listserv.uga.edu/archives/racf-l.html
>
>
>> We have an TSO application for end-users that allows them to update certain
>> VSAM and PDS files. In order for them to update
@LISTSERV.UA.EDU
Subject: RACF: Limiting update-authorization of a file to a particular
application
Greetings,
We have an TSO application for end-users that allows them to update certain
VSAM and PDS files. In order for them to update these files we of course
have to give their users update-authorization
Steff Gladstone wrote:
Please consider subscribing to RACF-L at
http://listserv.uga.edu/archives/racf-l.html
>We have an TSO application for end-users that allows them to update certain
>VSAM and PDS files. In order for them to update these files we of course have
>to give their users update
Greetings,
We have an TSO application for end-users that allows them to update certain
VSAM and PDS files. In order for them to update these files we of course
have to give their users update-authorization under RACF for those files.
We want to limit their ability to update the files only vi
29 matches
Mail list logo
