Re: Posting issues?

[Walt Farrell]

On Fri, 5 Apr 2024 15:36:21 -0400, Phil Smith III  wrote:

>Yeah, I have SPF records. 

But, increasingly, it seems to be necessary to have DMARC and DKIM properly 
setup, too. I don't know if that would explain your problem with this mailing 
list, though.

-- 
Walt

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

Re: DD SYMLIST?

[Walt Farrell]

On Wed, 21 Feb 2024 22:37:28 -0600, Paul Gilmartin  wrote:

>On Thu, 22 Feb 2024 13:45:18 +1000, Peter Vels  wrote:
>
>>https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-symlist-parameter
>>
>I'm  looking at Page 263 of  SA23-1385-60
>z/OS 3.1 MVS JCL Reference
>with the page heading DD: SYMLIST
>
>>On Thu, 22 Feb 2024 at 12:46, Paul Gilmartin  wrote:
>>
>>> What does the SYMLIST parameter of the JCL DD statement do?

What don't you understand about what the the reference provided by Peter says?

Did you look at the examples it provides?
https://www.ibm.com/docs/en/zos/3.1.0?topic=parameter-example-symlist

-- 
Walt

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

Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Walt Farrell]

On Mon, 15 Jan 2024 14:45:06 -0600, Joe Monk  wrote:

>How would that be practical? How would you, for instance, do a batch update
>to an encrypted dataset from a CICS vsam file?

Sorry; I don't understand the question. How do you do it today?

-- 
Walt

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

Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?

[Walt Farrell]

On Mon, 15 Jan 2024 16:15:38 +, Eric D Rossman  wrote:

>Answering a number of comments in order, in one message.
>
>First: I don't think being able to encrypt load libraries is worth it. 
>Encrypted executables, in general, are not going to increase security.
>
>Jousma, David:
>
>> Additionally, I think IBM dropped the ball a bit in that
>> nothing stops a permitted user to copy that data to an
>> un-encrypted dataset.
>
>Another topic we discussed. Here's the rub: How would you
>implement that? What would prevent one application from opening
>a data set and reading, then closing it and opening a new data
>set to write out. How would IBM detect that? I get that we could
>have prevented it for IDCAMS REPRO or similar programs but it
>would impossible to do it reliably for all possible programs.
>

RACF did something you could consider as a model, with EXECUTE access to 
programs. Once a user has loaded a program that they only have EXECUTE 
authority for (not READ), they cannot load another program that is not Program 
Controlled. (There's a bit more to it, but that's sufficient for this 
discussion, I think.)

For encryption, the analogous method might be: Once a jobstep has Opened an 
encrypted data set to read it, they cannot write to, nor Open, an unencrypted 
output data set. You just mark the jobstep, and have a bit in the DEB 
indicating encryption, and for a marked jobstep you don't allow a write to a 
DEB that doesn't have the bit set.

I can't say whether that would solve any real problems, but if there's a 
concern about someone reading an encrypted file and writing it unencrypted, 
that could solve part of it. The next layer, though, might be wanting to 
protect against them sending it over the network, and being sure how it's 
treated at the other end if they do.

-- 
Walt (former lead RACF designer/architect for that function)

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

Re: Help Trying to determine where abend occurred

[Walt Farrell]

Have you looked at the descriptions of the two fields?

From https://www.ibm.com/docs/en/zos/2.1.0?topic=us-important-fields-in-sdwa I 
see:


SDWAEC1
This field contains the PSW that existed at the time of the error.
SDWAEC2
The contents of this field vary according to the type of recovery routine:

For ESTAE-type recovery routines (except for ESTAI routines): If a 
program establishes an ESTAE routine, and subsequently performs a stacking 
operation while running under the same RB as when it established the ESTAE 
routine, SDWAEC2 contains the PSW from the linkage stack entry immediately 
following the entry that was current when the ESTAE routine was established. 
Otherwise, SDWAEC2 contains the current RBOPSW from the RB that activated the 
recovery routine, and the PSW is the one from the time of the last interruption 
of that RB that occurred while the RB was unlocked and enabled. Bit SDWAINTF in 
SDWAXFLG indicates whether the contents of SDWAEC2 are from the linkage stack 
(SDWAINTF is 1) or from an RB (SDWAINTF is 0).
For an ESTAI routine, this field contains zero.
For an FRR, the field contains the PSW used to give control to the FRR.


-- 
Walt

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

Re: RACROUTE REQUEST=AUTH problem

[Walt Farrell]

On Mon, 11 Dec 2023 09:50:34 -0600, John Blythe Reid  
wrote:

>The client never got the RACROUTE macro to work. Instead they've opted to use 
>the CICS command EXEC CICS QUERY SECURITY and that works ok. Does anyone think 
>that the problem may be due to issuing a RACROUTE macro inside a CICS 
>transaction ? However the same transaction does work on our LPAR but not on 
>the client's.

EXEC CICS QUERY SECURITY is what you're _supposed_ to use, and the last time I 
checked (many years ago) in most CICS configurations the user's ACEE is not in 
a location where RACROUTE would find it. That means that a RACROUTE would use 
the CICS region user ID, which is only one of the problems you need to deal 
with in trying to use non-CICS functions inside a CICS transaction.

I have no idea what CICS configuration you're running, nor what your client is 
running. And I have no idea how using the region's ACEE might return an RC=4. 
Usually I would expect an unwanted RC=0 or RC=8.

Nor do I have any idea what changes might have occurred in CICS in those 
intervening years.

-- 
Walt (former designer/developer on the RACF team at IBM)

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

Re: Usage: "data set" vs. "dataset"

[Walt Farrell]

On Sat, 25 Nov 2023 20:38:43 -0600, Paul Gilmartin  wrote:

>I believe that several years ago IBM Pubs decreed that "data set"
>rather than "dataset"  was preferred style and swept documentation
>emending the latter form.  It seems to be creeping back.  I just
>did a crude scan of the 3.1 .pdfs a d found 96260 occurrences of 
>" data set " vs. 1422 of " dataset " .  Should the latter be corrected?

Was your search case sensitive or insensitive?

If insensitive you would also pick up DATASET which is a keyword in RACF 
commands, for example. (And you would miss occurrences that involved 
capitalization at the start of a sentence, too.)

-- 
Walt

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

Re: Rexx to clone users in RACF

[Walt Farrell]

On Tue, 21 Nov 2023 12:23:24 +0400, Peter  wrote:

>Cloning  and creating one user is easy but
>
>I want to clone and create 10 userid at once .
>
>Is it possible to achieve it through DBSNC.?

DBSYNC can give you the commands to create 1 user based on another one.

Copy/Paste of those commands followed by a Find/Replace can give you a set of 
commands to create a second user.

Repeat as needed.

-- 
Walt

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

Re: Rexx to clone users in RACF

[Walt Farrell]

IBM used to, and may still, supply an unofficial REXX exec that I wrote named 
DBSYNC. One of its operational modes allows cloning a user, though I don't 
recall if that is described in the documentation or only anecdotally on RACF-L. 
And I have no idea where such tools & toys are distributed today, but someone 
on RACF-L could probably provide more information.

(And, arguably, RACF-L is a better place for a discussion about cloning RACF 
users than ibm-main, in my opinion :) )

-- 
Walt

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

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Walt Farrell]

On Sat, 11 Nov 2023 08:59:07 -0500, David S.  wrote:

>To help resolve a question posted to a LinkedIn group I manage:
>www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
>... I'd like to find out if there's any way to achieve *true*
>Skip-Sequential processing with a Fixed Block Sequential File with a fairly
>short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
>For example: Begin sequential processing at record number 100, *without*
>having to read the first 99 records.

As another user mentioned, you can't really read portions of blocks, so 
whatever block contains record number 100 would need to be read, which might 
give you some extraneous data transfer.

The real issue is your RECFM=FB. With FBS it would be possible, as with FBS you 
know that all blocks up to the final one are the same size, and that would 
allow you to calculate the block you needed. But with FB you could have short 
blocks in the middle, making it impossible to calculate where record 100 is 
located.

Another issue, I suppose, is what language you're writing in, as I believe only 
some access methods would allow you to position the file based on a block 
number.

-- 
Walt

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

Re: LISTSERV Trivia: Deleting drafts?

[Walt Farrell]

On Mon, 28 Aug 2023 15:21:55 -0500, Paul Gilmartin  wrote:

>I use the WWW interface to post to IBM-MAIN.  At times it tells me I have
>lingering drafts.  Each shows a trashcan  icon.  Clicking it usually fails
>or causes a window hang.  Is there a trick?
>
>I may have just discovered  that it works better to delete in (reverse)
>chronological order.  Is that what I should do?

I have no problems clicking the trashcon icon in the Drafts list, and it does 
not matter what order I delete them in.

Firefox on Windows, fwiw.

-- 
Walt

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

Re: Updating IEEMB846

[Walt Farrell]

On Wed, 23 Aug 2023 19:58:07 +0100, Lennie Dymoke-Bradshaw 
 wrote:

>Excellent. Now why didn't I think of that?
>Thank you Walt.

You're welcome, Lennie :) 

-- 
Walt

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

Re: Updating IEEMB846

[Walt Farrell]

On Tue, 22 Aug 2023 13:07:01 +0100, Lennie Dymoke-Bradshaw 
 wrote:

>I am trying to determine which users are using the TSO CONSOLE command.
>
>This is controlled one of those TSOAUTH checks that are done at LOGON time
>and the results of the RACF check are stored in the PSCB in bit PSCBCNAU. So
>many normal RACF checking monitors (such as zSecure Access Monitor) are of
>no use. I want to know who is using it, rather than who can use it.

Have you considered defining CONSOLE in the RACF PROGRAM class, allowing READ 
access to everyone, and setting appropriate AUDIT options?

-- 
Walt

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

Re: Colossal Cave on Android (was: Re: z/OSMF)

[Walt Farrell]

There are a number of hits that seem relevant when I do a search for "android 
version of dosbox", and once you have dosbox installed you should have access 
to a bunch of old DOS-based text games, including versions of Colossal Cave, I 
believe. I have not tried this personally, but I use dosbox on Windows and 
iPadOS for this purpose

https://duckduckgo.com/?q=android+version+of+dosbox=newext=v341-1=web

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

Re: A Discussion about RLSE on RAID Drives with Chat GPT-4

[Walt Farrell]

Thanks, Hobart.

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

Re: A Discussion about RLSE on RAID Drives with Chat GPT-4

[Walt Farrell]

On Thu, 29 Jun 2023 18:10:06 -0500, Hobart Spitz  wrote:

>https://chat.openai.com/share/1718b445-7a89-47a3-ab23-b670aa8c2211

That URL gives a 404 error, for me.

Perhaps you could have your conversation again, and quote the conversation here 
directly next time?

-- 
Walt

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

Re: RACF and Subject Alternate Name

[Walt Farrell]

On Thu, 8 Jun 2023 05:29:41 -0500, Michael Babcock  
wrote:
>
>And I simply don't see why RACF could not be made to generate more than
>one SAN.   Will that change with z/OS 3.1?

The RACF-L mailing list would be a better place for that part of your question, 
and (perhaps) for the complete question.

-- 
Walt

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

Re: IKJPARS PCL questions

[Walt Farrell]

On Sun, 30 Apr 2023 09:49:30 -0400, Joseph Reichman  
wrote:


>Do  the keywords have to be enter the way they are laid out in the PCL
>
>I would think not
>
>Because that's why they are keywords
>
>However when I don't enter them that way it does not  hit the validity exit

From earlier in the thread, if I remember correctly, you have a mix of 
positional and keyword operands. The positional operands must, of course, be 
first and in the proper order. But the keywords can be in any order

-- 
Walt

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

Re: TSO Rexx C2X Incorrect Output

[Walt Farrell]

On Thu, 27 Apr 2023 10:01:06 -0400, David Spiegel  
wrote:

>Had I thought (originally) that "Pull" was the issue,. I would've
>figured it out on my own.

Using the tracing functions in REXX to do the debugging, rather than browsing 
the data set itself, would also have been helpful.

-- 
Walt

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

Re: Check my math?

[Walt Farrell]

On Thu, 23 Mar 2023 09:34:02 -0500, John McKown  
wrote:

>I got curious about how many possible different values could exist in a
>dataset "node". A node can be 1 to 8 characters long. The first character
>must be A-Z @#$ or 29 characters. Subsequent characters are those 29 plus
>digits 0-9 and a dash (the dash was a surprise to me).

I think that set of restrictions is for _cataloged_ data sets. For 
_uncataloged_ data sets, there are no restrictions about the content of a data 
set qualifier except (possibly?) for the length.

-- 
Walt

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

Re: The Local death of DB2 z/OS --- what is the best way to preserve the data once the mainframe is gone

[Walt Farrell]

On Wed, 8 Feb 2023 14:31:02 -0600, Tom Longfellow 
 wrote:

>Excellent procedure and approach.   And a good path to maybe resurrecting the 
>application someday.
>
>I am still trying to sell the concept that a successful migration consists of 
>not only the data, But a least someway to CRUD (Create, Replace, Update, 
>Delete) data items.   PLUS in the relational case, the logical relationships 
>that link items that links things like invoices to users to addresses to 
>payments and who knows what else.   They are really going to miss their SQL 
>retrievals

If you can offload it to CSV (as instructed) and also to some kind of archival 
form that can be reloaded into SQLite (or other relational form) then when the 
users eventually revolt and management wakes up, you'll have something that can 
be restored to a usable form and satisfy the users (and the management that 
survives the revolt).

-- 
Walt

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

Re: Contents of "Command" field on standard login screen - where to find it

[Walt Farrell]

On Thu, 19 Jan 2023 15:02:06 +, Robert Prins  
wrote:

>And then you realise that the question should have been, "How do I get at
>it (control-block chasing-wise) in REXX?".
>

At what time in the user's logon, and where is the REXX exec running?

And why are you trying to do this from REXX? What problem are you really trying 
to solve?

-- 
Walt

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

Re: Location of forms code in z/OS manuals

[Walt Farrell]

On Wed, 26 Oct 2022 17:06:06 +, Seymour J Metz  wrote:

>PDFBox is certainly the way to go for the title, but IBM doesn't appear to be 
>putting the forms code anywhere accessible.

The form code is certainly in the text, e.g., at the bottom of the cover page. 
So you should be able to extract the first few pages (PDFtotext or another 
tool) and search for it. For example, using a regular expression to match 
something like SC23-6843-50.

-- 
Walt

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

Re: Fixed fields in regex (was: Trying to Parse a LISTCAT with SORT)

[Walt Farrell]

On Tue, 25 Oct 2022 10:33:23 -0500, Paul Gilmartin  wrote:

>On Tue, 25 Oct 2022 08:55:09 -0500, Walt Farrell wrote:
>>>>
>>>>>On Sat, 22 Oct 2022 04:09:43 +, Sri h Kolusu  wrote:
>>>>>>  %03=(ENDBEFR=C'.',FIXLEN=8),   # Node 3
>>>>>> ...
>>>>>Thanks.  I've wished for something line FIXLEN in regular expressions.
>>>>
>>>>Got an example of what you want in regular expressions?
>>>>
>>>NONVSAM --- MYFILE.ABLA.MIDDLE.N04.REPT3.NOTUSE
>>> DATASET-OWNER-(NULL) CREATION2022.200
>>>
>>>becomes:
>>>N04  REPT320220719 MIDDLE  
>>
>>Sorry; doesn't help. I should have been more specific, and started with "what 
>>does FIXLEN do that you'd want to see in a regular expression?"
>>
><https://www.ibm.com/docs/en/zos/2.5.0?topic=fields-parse-parameters>
>
>See the ply cited where Sri h Kolusu addressed the OP's requirement.  Could 
>this have been
>done in awk or sed with regular expressions?  In REXX I used LEFT() to achieve 
>the function.

Thanks for the doc reference.

So FIXLEN is applying to the output rather than the input. I don't think there 
are functions like that in standard regular expression processing, since it's 
about input parsing, not creation of output records. I have no idea if sed or 
awk have any specific functions like that for formatting their output, as I 
selecom use them. 
Sorry.

-- 
Walt

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

Re: Fixed fields in regex (was: Trying to Parse a LISTCAT with SORT)

[Walt Farrell]

On Sun, 23 Oct 2022 09:36:49 -0500, Paul Gilmartin  wrote:

>On Sun, 23 Oct 2022 08:59:09 -0500, Walt Farrell wrote:
>>
>>>On Sat, 22 Oct 2022 04:09:43 +, Sri h Kolusu  wrote:
>>>>  %03=(ENDBEFR=C'.',FIXLEN=8),   # Node 3
>>>> ...
>>>Thanks.  I've wished for something line FIXLEN in regular expressions.
>>
>>Got an example of what you want in regular expressions?
>>
>NONVSAM --- MYFILE.ABLA.MIDDLE.N04.REPT3.NOTUSE
> DATASET-OWNER-(NULL) CREATION2022.200
>
>becomes:
>N04  REPT320220719 MIDDLE  

Sorry; doesn't help. I should have been more specific, and started with "what 
does FIXLEN do that you'd want to see in a regular expression?"

-- 
Walt

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

Re: Trying to Parse a LISTCAT with SORT

[Walt Farrell]

On Sat, 22 Oct 2022 10:03:49 -0500, Paul Gilmartin  wrote:

>On Sat, 22 Oct 2022 04:09:43 +, Sri h Kolusu  wrote:
>>...
>>  %03=(ENDBEFR=C'.',FIXLEN=8),   # Node 3
>> ...
>Thanks.  I've wished for something line FIXLEN in regular expressions.

Got an example of what you want in regular expressions?

(Possibly best to start a separate thread/topic, though :) )

-- 
Walt

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

Re: CSNBENC rc=8 rsn=X'271C'

[Walt Farrell]

On Wed, 12 Oct 2022 09:51:36 +0100, Lennie Dymoke-Bradshaw 
 wrote:

>It was Pierre's previous posts about replacing a password using ICHEINTY and 
>R-admin.
>Maybe I have mixed up two distinct issues.

Perhaps, but that earlier/ongoing thread talking about "having a RACF encrypted 
password" and "having used CSNBENC to get it" certainly seems like they 
_should_ be related :) 

-- 
Walt

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

Re: LONGPARM applies?

[Walt Farrell]

On Tue, 27 Sep 2022 13:50:14 -0500, Paul Gilmartin  wrote:

>
>Breaking an existing authorized program in that fashion could be a buffer
>overrun leading to escalation of privilige; an integrity threat that I'd 
>consider
>an incompatibility.

But are you talking about PARM=, which Peter has covered (long parms not 
allowed unless specified by the authorized program's directory entry), or about 
the APIs you mentioned (LINK, ATTACH, etc.)?

For the APIs, you can only "break" the existing authorized program if you (the 
program issuing the API call) are also running authorized. If you're not 
authorized, the program you're invoking won't run authorized, either, and 
there's no integrity exposure.

-- 
Walt

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

Re: DFSORT: BRE vs. ERE

[Walt Farrell]

On Fri, 2 Sep 2022 14:39:22 +, Sri h Kolusu  wrote:

>>> How can the programmer select which of the two supported versions DFSORT 
>>> will use?  The later examples seem to show only EREs or to be neutral.  An 
>>> example showing a BRE instead would be useful.
>
>Paul,
>
>Since both versions are supported, it is up to the programmer to use whichever 
>version fits his requirements.  We will try to add an example for BRE.

Yes, the programmer needs to know which version fits their requirements.

However, some of the basic reg-ex operators function _differently_ in BRE than 
in ERE. Therefore there must also be a way for the programmer to tell you 
whether to use BRE or ERE.

How does the programmer do that?

-- 
Walt

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

Re: DFSORT: BRE vs. ERE

[Walt Farrell]

On Fri, 2 Sep 2022 07:33:27 -0500, Paul Gilmartin  wrote:

>In DFSORT Application Programming Guide:
>INCLUDE Control Statement
>Regular expressions
>...
>Two versions of regular expressions are supported:
>• Basic Regular expressions (BRE)
>• Extended Regular expressions (ERE)
>
...
>
>How can the programmer select which of the two supported
>versions DFSORT will use?  The later examples seem to show
>only EREs or to be neutral.  An example showing a BRE
>instead would be useful.
>
>Should I submit a RCF?

An RCF would be appropriate, I think.

Purely as a guess: The regular expression "mode" (BRE, ERE) might be set using 
an options string at the beginning of the regular expression. For example, 
according to https://www.regular-expressions.info/modifiers.html if you were 
processing regular expressions in Tcl, you would use (?b) at the beginning of 
the expression to force BRE mode, and (?e) to force ERE mode. It is possible 
that this or something similar would work in DFSORT's engine.

It's fairly common, in my experience with different regex engines, for some set 
of the options shown on that page to be supported.

-- 
Walt

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

Re: Calculate deltas using DFSORT

[Walt Farrell]

On Wed, 31 Aug 2022 11:13:57 -0500, Paul Gilmartin  wrote:


>>In any case, "[^abc]" does not match "wombat". It matches only a single 
>>character of a string. So, it might match the "w" in "wombat", or the "o", or 
>>the "m", or the "t", depending on other details of the input string being 
>>processed, and the application doing the processing.
>> 
>Absent an anchor ("^" and/or "$") a pattern can be matched anywhere in a 
>subject.

Good point. Thanks.

>
>>I agree with your comment (which I omitted from my quote) that the DFSORT 
>>books should not try to explain reg-ex processing, unless they have written 
>>their own processor instead of reusing someone else's.
>>
>+1
>But it might be proper to emphasize any difference between DFSORT's use of
>reg-ex and traditional beliefs.

But, whose "tradition"? PERL, PCRE, Python, Boost, ...

Does the DFSORT documentation name a standard that they've implemented?

-- 
Walt

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

Re: Calculate deltas using DFSORT

[Walt Farrell]

On Wed, 31 Aug 2022 16:35:27 +, Sri h Kolusu  wrote:


>>>The DFSORT manual (and others) should not attempt to explain regular 
>>>expressions.  They should defer to citing a single publication with such an 
>>>explanation.
>
>I completely agree, however each component within IBM is implementing a 
>regular expression flavor. Different regular expression flavors are not fully 
>compatible with each other. So it is difficult to have 1 central publication.

Perhaps, if you're implementing a specific, standard reg-ex flavor (e.g., PERL, 
or PCRE, or one of the Boost libraries) you could consider just pointing to the 
standard documentation. You would then only need to document exceptions to the 
standard behavior.

-- 
Walt

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

Re: Calculate deltas using DFSORT

[Walt Farrell]

On Wed, 31 Aug 2022 10:03:21 -0500, Paul Gilmartin  wrote:

>
>"[^abc]" matches any string containing a character
>other than a, b, or c.  It matches "wombat".  However,
>"^[^abc]*$" matches strings containing no character
>other than a, b, or c.   It does not match "wombat".

Was that something you said, or something you're quoting from the manual? I'm 
not sure.

In any case, "[^abc]" does not match "wombat". It matches only a single 
character of a string. So, it might match the "w" in "wombat", or the "o", or 
the "m", or the "t", depending on other details of the input string being 
processed, and the application doing the processing.

I agree with your comment (which I omitted from my quote) that the DFSORT books 
should not try to explain reg-ex processing, unless they have written their own 
processor instead of reusing someone else's.

-- 
Walt

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

Re: GLOBAL OPERCMDS ACTIVATION

[Walt Farrell]

On Wed, 24 Aug 2022 09:55:56 -0500, Michael Babcock  
wrote:

>I’m trying to define the MVS.MCSOPER.*/READ profile global class.
>
>I issued the following in batch:
>
> RDEF GLOBAL OPERCMDS OWNER(PXX) UACC(NONE)
>ADDMEM(MVS.MCSOPER.*/READ)
>
>READY
>
> SETROPTS GLOBAL(OPERCMDS)
>REFRESH
>
>ICH14016I CANNOT REFRESH OPERCMDS, GLOBAL ACCESS CHECKING
>INACTIVE.
>
>OPERCMDS doesn’t show up in the GLOBAL CHECKING CLASSES either.
>
>I do have the GLOBAL DATASET class active
>
>What am I doing wrong?

Sounds like you do not have GLOBAL OPERCMDS active: SETR GLOBAL(OPERCMDS)

-- 
Walt

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

Re: rexx and IDCAMS functions

[Walt Farrell]

On Mon, 22 Aug 2022 16:16:06 -0500, Paul Gilmartin  wrote:

>Why is there an AUTHPGM NAMES list at all?  Why shouldn't it just be
>* (everything)
>???
>
>I can imagine several reasons:  Even some authorized programs might not
>be trusted not to modify the WAITing TSO task (IKJEFTT09?), perhaps by
>ALLOCATE REUS of a file TSO uses.  Or by modifying TSO storage.  Or
>by monopolizing a scarce resource (such as a tape drive) during programmers' 
>think time.  BTDT; alas no distinction is made between real tapes and virtual
>tapes which are more likely to be plentiful.
>
>Is the motive one of these, or something similar?

I cannot provide a definitive answer to that, as I was not involved in any of 
the design for that function. 

I can, though, guess that they did not want to assume that every APF-authorized 
program would behave properly when invoked authorized but in an unexpected 
environment, and therefore chose to restrict them unless IBM or a customer had 
specifically listed them as "safe".

>
>This feels like something that should be programmer-specific , such as a RACF
>profile allowing Lizette but not me the facility.
>

I don't see a need for saying "program X can run APF-authorized under TSO if 
Lizette runs it, but not if Paul runs it. That is not a function that exists 
when you run a program in batch, for example, and if it were to be meaningful 
in TSO it would also be meaningful in batch.

You can control which users can run which programs (PROGRAM control in RACF, 
though that came later than AUTHPGM), and if an APF-authorized program is doing 
something that should be restricted further, it can do its own restource 
checking (as AMASPZAP does when zapping a VTO).

-- 
Walt

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

Re: rexx and IDCAMS functions

[Walt Farrell]

On Mon, 22 Aug 2022 09:47:44 -0500, Paul Gilmartin  wrote:

>On Mon, 22 Aug 2022 09:42:25 -0500, Walt Farrell wrote:
>
>>>I forgot to mention that "IDCAMS" is included on the
>>>SYS1.PARMLIB(IKJTSOxx)) AUTHPGM NAMES list
>>
>>Yes, that would be required in order for your TSO CALL command to invoke 
>>IDCAMS with APF-authorization.
>> 
>Why is such specific authorization required?  Is there some
>associated hazard or cost?

If you're asking why she needs to run IDCAMS APF-authorized, it's because 
IDCAMS is normally run APF-authorized, and although some IDCAMS functions will 
work if the program is not running authorized, others (e.g., DCOLLECT) won't 
work without APF-authorization.

If you're asking something else, please clarify.

-- 
Walt

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

Re: rexx and IDCAMS functions

[Walt Farrell]

On Mon, 22 Aug 2022 15:39:52 +, Seymour J Metz  wrote:

>Why do you say that? The CALL command is a very different animal from ADDRESS 
>LINKMVS.

As I recall, Lizette said she was mandated to use LINKMVS. And as we have 
pointed out, for her purposes, LINKMVS will not work.

I think Jack was suggesting that using the TSO CALL command as an alternative 
would work, and questioning why she can't do that instead. (In other words, 
_why_ she is mandated to use LINKMVS, when it is the wrong tool.)

-- 
Walt

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

Re: rexx and IDCAMS functions

[Walt Farrell]

On Mon, 22 Aug 2022 14:01:46 +0100, Jack Zukt  wrote:

>I forgot to mention that "IDCAMS" is included on the
>SYS1.PARMLIB(IKJTSOxx)) AUTHPGM NAMES list

Yes, that would be required in order for your TSO CALL command to invoke IDCAMS 
with APF-authorization.

-- 
Walt

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

Re: rexx and IDCAMS functions

[Walt Farrell]

On Sat, 20 Aug 2022 13:28:29 -0700, Lizette Koehler  
wrote:

>I think what I am having a challenge with is the STGADMN.IDC.DCOLLECT in 
>Facility Class
>
>The UACC is NONE but the ACL has   *  READ
>
>The process creates the JCL Statements in ALLOC statements.  SYSIN will 
>contain the DCOLLECT control card
>
>Then it just does a LINKMVS  to SYS1.LINKLIB(IDCAMS)
>
>Almost like what you would code in Batch JCL.
>
>I was requested to make this work, If I had a choice I would definitely change 
>it

DCOLLECT requires APF authorization.  
https://www.ibm.com/docs/en/zos/2.3.0?topic=program-authorized-facility-apf

REXX execs do not normally run APF-authorized (thus my request for more 
information on where your exec is running, which you did not provide), and 
therefore ADDRESS LINKMVS will not normally work to invoke IDCAMS if you want 
to run DCOLLECT.

-- 
Walt

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

Re: rexx and IDCAMS functions

[Walt Farrell]

On Tue, 16 Aug 2022 19:49:16 -0700, Lizette Koehler  
wrote:

>I am actually using LINKMVS  and that is getting the error
>
>I want my general user to be able to do things without knowing idcams

What, exactly, does your code do, Lizette? What are you invoking with LINKMVS, 
and what are you passing to it? What environment is your REXX exec running in?

-- 
Walt

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

Re: Looked at Destination Z lately?

[Walt Farrell]

On Fri, 1 Jul 2022 10:07:34 -0700, Tom Brennan  
wrote:

>archive.org shows it was used by IBM, but years ago.

Thanks.

Looks like it was still in use on Feb. 18, 2020, but it became a redirect to 
community.ibm.com by Aug. 1, 2020, according to the Wayback Machine.

-- 
Walt

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

Re: Looked at Destination Z lately?

[Walt Farrell]

On Fri, 1 Jul 2022 00:07:27 -0400, Gabe Goldberg  wrote:

>www.destinationz.org isn't quite what one would expect for IBM's
>mainframe community website.
>
>Did someone let domain registration expire, was it hacked or redirected?

Was it ever used for that purpose? I see no Google references to that URL, and 
the only IBM-related Destination Z site seems to be:
https://community.ibm.com/community/user/ibmz-and-linuxone/groups/destinationzhome

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

Re: How To Handle RACROUTE logic

[Walt Farrell]

On Mon, 27 Jun 2022 10:20:43 -0500, Mike Cairns  wrote:

>One important difference you might need to be aware of is between a normal 
>RACROUTE call that executes under the authority of the current user associated 
>with the running address space (a First Party call - i.e. checking your own 
>current access rights), and the special case known as Third Party RACROUTE 
>call where you also give the userid on the call and it's not necessarily the 
>same userid as you are executing under at the time.  For this, you need first 
>to create a new RACF ACEE and pass this to the RACROUTE call - IIRC this 
>*requires* you to have APF Authorisation (actually, Supervisor State, however 
>you get that, but most commonly this means you are APF'd), IOW you won't be 
>doing this from a normal user address space.

More correctly, Mike, to create an ACEE or specify a userid on the AUTH call 
(which tells RACF to create an ACEE for that user) you need to be authorized: 
any of APF, supervisor state, or system key will work.

Another caveat: If this is happening in CICS, the code should be using CICS 
services, not RACROUTE, to do any checking.

-- 
Walt

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

Re: Large block interface for VB

[Walt Farrell]

On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman  
wrote:

>I have 100 files concatenated that are normally processed by qsam with a lrecl 
>31996 and blksize 32000
>
>Since processing takes a long time I was looking to speed things up by 
>specifying a blksize of 32 in the DCBE 
>
>After the first read using bsam read macro I looked at the first 4 bytes ( 
>Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to me 
>that it was still processing blksize of 32,000 

I'm surprised no one has mentioned it, but for input files, the blocksize is 
determined by the application that wrote the file. The application that is 
reading has no control over it. If you're reading a block, it is as long as it 
is, and no longer.

In theory, using EXCP, you could read using CCWs with data chaining that would 
read multiple blocks in one I/O operation and concatenate them into one data 
area. But that would be complex, and (I think) unlikely to get significantly 
better performance than simply increasing the number of channel programs that 
QSAM uses.

-- 
Walt

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

Re: Unable to ALLOC dsn without new

[Walt Farrell]

On Tue, 24 Nov 2020 10:35:40 -0600, Elaine Beal  wrote:

>I give up :), asking for help
>
>Defining a new user and logon proc issues
>
>SET  =
>ALLOC FI(ISPPROF) SHR  DA('')
>
>the dsn is new and evidently the alloc fails
>
>but i can manually alloc a new dsn without the new parm (under another ID)
>
>if I try a manual allocate with the failing ID (and no new parm), it fails with
>
>ALLOC FI(ISPPROF) SHR  DA('gayleyc.isptabl')
> DATA SET GAYLEYC.ISPTABL NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED 
> ENTER DATA SET NAME -  
>
>I thought you had to have the new parm but i can ALLOC a new dsn under another 
>id without it.
>
>The ALLOC proc works on another LPAR.

Why are you saying SHR? That indicates that the data set already exists. 

If this was in JCL, NEW would be the default if you don't say NEW, OLD, or SHR. 
But if you say SHR the data set must already exist. I don't know if TSO will 
similarly default to NEW if you omit SHR, but it seems correct for it to 
complain if you say SHR when the data set does not exist.

-- 
Walt

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

Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?

[Walt Farrell]

On Tue, 29 Sep 2020 16:59:34 -0700, Charles Mills  wrote:

>Applications should not "validate" filenames before attempting to open or 
>create a file. Present the name to the file system API and report any error 
>back to the user. Application filename validation is what leads to these 
>inconsistencies.

I will strongly agree with that, Charles.

It goes along with not trying to pre-check the security results of something 
like opening or creating a file. They should just try to take the action as 
requested by the user, and if the system fails the operation they should report 
the failure. There are too many possibilities of error in trying to duplicate 
the security requests the system will make anyway, which could lead to either 
false positive or false negative results, or compromise auditing. Let the 
component that is responsible for the security make the security decision.

-- 
Walt

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

Re: blanks at the end of Unix file names - was LMINIT cannot handle concatenation with more than 16 data sets?

[Walt Farrell]

On Tue, 29 Sep 2020 19:58:06 -0500, Paul Gilmartin  wrote:

>On Tue, 29 Sep 2020 16:59:34 -0700, Charles Mills wrote:
>
>>Applications should not "validate" filenames before attempting to open or 
>>create a file. Present the name to the file system API and report any error 
>>back to the user. Application filename validation is what leads to these 
>>inconsistencies.
>> 
>I'll emphasize that.  Applications and UIs should not modify filenames -- add 
>blanks;
>remove blanks; change case, etc.  A related problem arose a while ago when the
>requirement (possibly delusional) for mixed-case passwords appeared.  Many
>applications which though they were doing a users a favor by converting 
>passwords
>to upper case had to be modified.  The operation should always have been left 
>to
>the security product.

RACF required applications to present the password in upper-case, so the 
applications were not at fault for doing so. Blame RACF for that one.

-- 
Walt

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

Re: Query ESM from REXX

[Walt Farrell]

On Mon, 3 Aug 2020 04:16:38 +, Gadi Ben-Avi  wrote:

>But that would mean checking if the user has access, or if the user has access 
>through any of the groups it is connected to. 

If I remember correctly, if the user can see anything from the profile that 
protects the resource then he has at least READ access somehow. So that should 
provide your answer. So running IRRXUTIL and querying the profile that protects 
the resource should provide the answer you need.

However, I'd be careful doing this. First, of course, you have the Time Of 
Check To Time Of Use problem, and after you make your check the user may lose 
access.

Next, you need to worry about where the REXX exec runs. If it runs in the 
user's address space then there are ways the user might bypass your check.

Finally, if your REXX exec is going to do something that will also perform a 
security check, then it's generally better to just attempt the operation and 
let the real enforcement happen. If you try to make a check yourself you may 
get false positives or false negatives, depending on TOCTTOU and/or how the 
security administrators decided to setup the profile and access lists.

-- 
Walt

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

Re: HOW DO I VERIFY A USERID'S ACCESS TO A DATASET

[Walt Farrell]

On Sat, 13 Jun 2020 23:32:02 -0400, Bob Bridges  wrote:

>Gil, you mustn't think I plan to make it a habit but I think I'm going to 
>disagree with you on every point, here:
>
>o Well, maybe not on the first one:  What's "TOCTTOU"?

Time Of Check To Time Of Use. As you're making the check, a security 
administrator might be changing the rules. Your program might end up getting a 
false positive or false negative.

>
>o Access rules are indeed complicated to simulate.  But why simulate them?  
>Just
>  ask RACROUTE and get an answer.  Mind you a) I'm a security geek, so maybe 
> the
>  rules seem less complicated to me.  And b) I've never used RACROUTE directly;
>  as a security geek I talk to RACF/ACF2/TSS through their TSO-level commands,
>  so maybe RACROUTE is more difficult.

The rules for properly issuing RACROUTE REQUEST=AUTH are what is complicated. 
Ignoring resources other than MVS data sets, you need to process differently 
for non-VSAM vs VSAM.

For either, you need to first check whether the data set is indicated as 
possibly having a discrete profile. For non-VSAM, that means reading the DSCB 
from the VTOC. For VSAM, it means reading the (if I remember correctly) Sphere 
record from the proper catalog (which you also have to figure out) to determine 
the cluster name. Then you need to read the RACF indicator from the catalog 
entry for the cluster name (not the component name you may be opening).

Then, for VSAM, you need to specify the cluster name (not the component name 
that may appear in the JCL).

Failure to do any of those properly will give you a potentially wrong answer, 
or an answer that is right in many cases but wrong in edge cases.

Then, there is the difficulty that if your program is not the one that will 
actually do the OPEN, you may simply get the wrong answer because RACF allows 
access rules like "user X can use data set Y but only when running program Z". 
If you are not part of program Z, the answer you get from the RACROUTE will 
differ from the answer that Z would get if it actually performed the OPEN. So, 
you might get the wrong answer, and again it might be a false positive or a 
false negative.

Also, if your program is not running authorized, or (more precisely) does not 
actually require authorization, there are ways a clever user can bypass the 
check you're doing if your program is running in an environment they can 
control, such as TSO or batch or a UNIX shell.

There are additional considerations if you are asking about the authority of a 
user other than the one you're running under.

It is much simpler, and safer, and in general more robust, to simply issue the 
OPEN in the proper program environment and let the system say Yes or No. 

-- 
Walt (former member of the RACF Design/Development team)

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

Re: S0F9 and SOFD ABENDs and SVC dumps - oh my!

[Walt Farrell]

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 force because IMS intercepts that and 
>> tells you to terminate the IMS region by de-registering it from IMS.
>...
>
>How does IMS (or anyone else) "intercept" a FORCE? Is it watching the
>command interface (SSI) or some such anti social behaviour?

If I remember correctly, from research many years ago, yes, it's tied in to the 
SSI.

-- 
Walt

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

Re: Mainframe user ID length

[Walt Farrell]

On Thu, 30 Apr 2020 19:46:04 +, Frank Swarbrick 
 wrote:

>Is z/OS still limited in all cases to 8 upper case characters?  I am curious 
>if a user that only has access to MQ might be able to have a longer and
>ideally mixed case user ID.  They wouldn't have access to TSO or CICS or IMS.

It is in theory possible for an application (such as MQ) to use z/OS security 
services to map an alternative identity (which might have different 
characteristics from a z/OS user ID) into a standard z/OS user ID.

That can be done, for example, when applications support authentication via 
digital certificates, or via Kerberos (e.g., Windows Active Directory), or via 
LDAP. And there are additional mechanisms besides those three that z/OS 
supports.

I have no idea whether MQ supports any of those alternative mechanisms, nor 
which ones, nor whether they're applicable in your environment.

-- 
Walt

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

Re: 64-bit application dump analysis [was: RE: Problems with ESTAEX invoked in AMODE 64 . . . ]

[Walt Farrell]

On Thu, 26 Mar 2020 13:10:18 -0500, Paul Gilmartin  wrote:

>On Thu, 26 Mar 2020 17:54:58 +, Seymour J Metz wrote:
>
>>ObSchiller IPCS is part of z/OS. All dangerous facilities of IPCS are 
>>controlled by SAF. If your management capriciously prohibits you from using 
>>it, the responsibility is theirs. It's certainly their prerogative to ban, 
>>e.g., IEFBR14, but no outside company is obligated to rescue them from the 
>>consequences of their decision.
>>
>>Not all companies take essential tools away from their application developers.
>>
>I take your mention of IEFBR14 as hyperbole.  But I have heard of sincere
>admin objections to application programmers' use of AMASPZAP, ADRDSSU,
>and CMS DDR.
>
>Is there perhaps not a security but a performance concern with IPCS?
>

There is neither a security nor a performance issue. Merely a lack of education 
on the part of those administrators, in my opinion.

-- 
Walt

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

Re: How many ways can one sentence be wrong dept

[Walt Farrell]

On Sun, 12 Jan 2020 09:27:52 +, Jeremy Nicoll 
 wrote:

>On Sun, 12 Jan 2020, at 04:24, Phil Smith III wrote:
>> From a book:
>>
>> "... located a Trojan virus during a routine mainframe defrag."
>
>I dunno about the first bit, but "routine mainframe defrag" is fine.
>DFDSS has a DEFRAG verb.

However, one does not "defrag a mainframe." One defrags a storage volume, which 
might happen to be attached to a mainframe.

-- 
Walt

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

Re: AUTHPGM in IKJTSOxx

[Walt Farrell]

On Wed, 4 Dec 2019 01:28:39 +, Lennie Dymoke-Bradshaw 
 wrote:

>Jesse / Skip,
>
>This is actually defined as being a requirement in "DFSMS Access Method 
>Services Commands" SC23-6846-30. See Page 6, or just search for AUTHCMD and 
>you will quickly find it. It states the following,
>
>"To use IDCAMS and some of its parameters from TSO/E, your system programmer 
>must update the system by one of these means:
>. Update the IKJTSOxx member of SYS1.PARMLIB. This is the method that IBM 
>recommends. Add IDCAMS to the list of authorized programs (AUTHPGM). If you 
>want to use SHCDS, SETCACHE, LISTDATA, DEFINE or IMPORT from TSO/E, add them 
>(and abbreviations) to the authorized command list(AUTHCMD).
>. Update the IKJEGSCU CSECT instead of IKJTSOxx, see z/OS TSO/E Customization 
>for more information."
>
>This does not introduce the exposure that placing IDCAMS into AUTHPGM does. 
>Several forms of DEFINE require APF authorisation.

There is no exposure, today, with having IDCAMS in the AUTHPGM list. There was, 
I believe, in the distant past before the AUTHTSF list was created. There would 
be an exposure putting IDCAMS in the AUTHTSF list.

For more: 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjb700/ikjb700_Program_Authorization_and_Isolation.htm

-- 
Walt

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

Re: AUTHPGM in IKJTSOxx

[Walt Farrell]

On Mon, 18 Nov 2019 20:03:59 +, Seymour J Metz  wrote:

>What do you mean by "the initial program"? The TMP doesn't need to be in any 
>list.
>
>There are a few caveats on authorization.
>
>   Whether the entire linklist is autoorized depends on what you have in 
> PARMLIB.
>
>   Anything in the LPA is authorized.

No, but that's a common misconception (or, perhaps, a common mis-statement).

The correct statement is: anything in LPA is considered to reside in an 
authorized library.

What that means is:
1. It can be loaded by something that is running either unauthorized or 
authorized (APF, system key, or supervisor state). When loaded, the state of 
the running program's authorization is not changed. (I will ignore the further 
complications that can be imposed by RACF Program Control, as those are not 
really related to authorized vs unauthorized.)

2. If it is loaded by the Initiator as a jobstep program, and it is linked 
AC(1), it will run APF-authorized. (I will ignore possible JOBLIB/STEPLIB 
effects.)

3. If it is run under TSO and is in the appropriate IKJTSOxx list (AUTHPGM, 
AUTHCMD, AUTHTSF) for the way it was run, it will run APF-authorized. (Again, 
ignoring possible JOBLIB/STEPLIB effects.)

But it is only truly "authorized" if it is loaded by an already-authorized 
program in case 1, or when cases 2 or 3 apply.

-- 
Walt

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

Re: AUTHPGM in IKJTSOxx

[Walt Farrell]

On Mon, 18 Nov 2019 10:54:06 -0500, scott Ford  wrote:

>So guys, stupid question what about a STC that provisions for RACF, etc.
>But the design is as a normal generalized user, but with a id
>with SPECIAL that is invoked only during the time of passing the command to
>RACF ? Does it have to be APF authorized for RACF command
>access or am i misunderstanding my readings ?

If the program starts out under user ID A, and needs to switch to user ID B (as 
you seem to indicate it does), then it will need some kind of authorization to 
switch its identity.

That authorization could be APF-authorization, or supervisor state, or system 
key. Or if the program is running in a UNIX System Services environment on z/OS 
and the program has appropriate UNIX server authorization, it could use UNIX 
functions to change its identity.

So without more details we can't say what your program would need to do, or 
exactly what kind of authorization it would need.

-- 
Walt

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

Re: AUTHPGM in IKJTSOxx

[Walt Farrell]

On Sun, 17 Nov 2019 19:10:16 -0600, Paul Gilmartin  wrote:

>On Sun, 17 Nov 2019 15:50:53 -0600, Walt Farrell wrote:
>
>>On Sun, 17 Nov 2019 00:33:29 +, Leonardo Vaz wrote:
>>>
>>>But wouldn’t that program be system integrity even if not placed on AUTHPGM? 
>>>The user could execute it batch first example and change his ACEE or 
>>>anything else.
>>
>>No, that wouldn't be a problem, ...
>> 
>I respectfully differ.  A program executed as the job step task and
>running in authorized state which can branch to an arbitrary address,
>not necessarily an entry point, in its address space, even in its own
>code, specified by a non-privileged user presents an indeterminate
>hazard.

I think you're right, gil for some scenarios I didn't consider initially. But 
the scenario most analogous to the TSO one, which I mentioned, where the user 
executes his own program that invokes the program we're talking about by 
calling it (LINK, etc.) doesn't have a problem. In that scenario the user's 
program isn't running authorized, and therefore the program it calls isn't 
running authorized, either.

So the user is going to have to be more clever than that to pass an address of 
some code that can cause a problem, while still getting the program invoked 
with authorization.

But as it can probably be done somehow, the idea of having a program like that 
was unwise from the beginning. I'll have to think about some other things that 
an authorized program running under TSO might have to account for that it 
wouldn't in another environment.

-- 
Walt

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

Re: AUTHPGM in IKJTSOxx

[Walt Farrell]

On Sun, 17 Nov 2019 00:33:29 +, Leonardo Vaz  wrote:

>
>But wouldn’t that program be system integrity even if not placed on AUTHPGM? 
>The user could execute it batch first example and  
>change his ACEE or anything else.

No, that wouldn't be a problem, because if the user wrote his own program and 
ran it in batch it would not be running APF-authorized, and nothing it called 
would be running APF-authorized, and so the program I described wouldn't be 
able to do any harm. Anything that program could do, running unaurhorized, the 
user could do directly.

It is purely having the program named in AUTHPGM, and running it in a TSO 
environment, that causes the System Integrity exposure.

>
> I guess depending on the authorized program code, it might keep integrity 
> when executed under its own address space but if it executed  
>under TSO it might allow other units of work to run something they shouldn’t 
>be able to, i think it would have to be something really specific  
>and it’s still unclear to me why AUTHPGM exists.

AUTHPGM exists to allow some authorized programs to run under TSO, when they 
are needed under TSO and they are known to properly maintain MVS System 
Integrity. But the author of the program needs to understand MVS System 
Integrity, and the system programmers in charge of AUTHPGM need to understand 
the ramifications of putting programs into that list. They should only do that 
for programs written by someone they trust, and when the author has indicated 
that it's safe to put the program in AUTHPGM.

-- 
Walt

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

Re: AUTHPGM in IKJTSOxx

[Walt Farrell]

On Sat, 16 Nov 2019 15:30:01 +, Leonardo Vaz  wrote:

>I am curious now, does a custom homegrown program have to take extra 
>precautions to be placed under AUTHPGM? What would those be?
>

Usually, no.

Sometimes, depending on what the program does, yes.

For example, consider a program which accepts as a parameter the address (not 
the name) of some code to be executed as a kind of subroutine. 

Now consider what might happen if you were to link that program with AC(1), 
place it in a library that MVS considers APF-authorized, and put its name in 
AUTHPGM. At that point any TSO user could:
(1) Write a program that had some malicious code in it.
(2) Invoke your program using IKJEFTSR and passing the address of the malicious 
code.

TSO would then pause the user's program (TCB) to preserve System Integrity, 
invoke your code running authorized, and your code would run the user's 
malicious code. Your program has then allowed the user to violoate MVS System 
Integrity.

There are several solutions:
(a) Don't put that program in AUTHPGM. If I remember correctly there was at 
least one MVS program whose documentation said it should not be placed in 
AUTHPGM.

(b) Code the program to detect it's running authorized, and under TSO, and then 
skip calling the code. Perhaps, as an alternative, in that situation the 
program might allow the user to pass a module name instead of an address, and 
the program could LINK to it, allowing the system to determine whether it is 
safe to invoke the subroutine module.

(c) Code the program to detect it's running authorized, and under TSO, and then 
to perform a security check to see the current user is trusted to run the 
program under TSO. 

-- 
Walt

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

Re: SVC dump data set layout

[Walt Farrell]

On Fri, 25 Oct 2019 09:30:27 -0500, Steve Horein  wrote:

>However, with the name, I can leverage some tools to open and read the data
>set to get pertinent info. For example, this NetView PIPE recipe can get
>what appears to be the TITLE and JOBNAME from the first record at columns
>89 and 1151:
>WINDOW PIPE QSAM SYS1.DUMP.CP66.D190419.T043130.S1|TAKE FIRST 1
>LINE|EDIT 89.100 1 "¢" NW 1101.8 N "¢" NW 1151.150 N|SPLIT AT "¢"|CONS ONLY

Why not issue the MVS Display Dump command, which has an option to display the 
dump title.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieag100/d3dump.htm
 has more information (for z/OS 2.2).

-- 
Walt

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

Re: Submitting batch if you don't have TSO

[Walt Farrell]

On Wed, 11 Sep 2019 12:15:11 -0500, Paul Gilmartin  wrote:

>As I follow this thread, I wonder why CICS doesn't submit batch jobs
>with the credentials of the requesting individual rather than the CICS
>region.

Some of the IBM CICS designers over the years have wanted to allow that. The 
IBM z/OS Security and Integrity teams (in my time) strongly resisted that 
because with the design of CICS it's not safe.

Yes, CICS verifies the user's identity with RACF (or other security product) 
but after that there are storage isolation issues in a multi-user environment 
such as a CICS region that make it impossible for the system to trust the 
user's identity sufficiently to allow it to propagate to another environment 
such as a batch job.

Note that this is a fundamental issue with mult-user address spaces that run 
customer- or user-provided code, not just with CICS. 

It can be mitigated by vigilant and vigorous inspection of all the customer- 
and/or user-provided code that will run in the region. However, it can only be 
truly resolved by appropriate protection and isolation of both the control 
blocks that prove a user's identity and the transaction code. And, 
unfortunately, providing that isolation has performance implications and might 
require hardware changes.

Those performance implications were considered unacceptable for a CICS 
environment. We had some interesting discussions over the years investigating 
potential CICS or z/OS software changes, possibly coupled with z hardware 
changes, that could allow protection and propagation of the user's identity 
safely, but none of them resulted in satisfactory solutions that would also 
maintain the required level of performance.

-- 
Walt (former SAF and RACF Designer/Developer, for those who may not know)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Email validation (was Re: Mainframe Report meets abrupt end | Computerworld Shark Tank)

[Walt Farrell]

On Wed, 24 Apr 2019 12:10:59 -0500, John McKown  
wrote:

>>
>> 
>> Why are passwords restricted to a maximum length of 8, and passphrases
>> restricted to a minimum length of 9?
>>
>
>Passwords are restricted to a max of 8 for historical reasons. They were
>once kept in SYS1.UADS -- the TSO repository for userids, passwords, and
>TSO information in the beginning (pre RACF). Why 8? Probably because
>everything else was of length 8, i.e. a doubleword. Passphrases are 9 or
>more characters so that RACF will know that it is a passphrase and not a
>password. I guess the developers went with the easy to test rule of "8 or
>less is a PASSWORD, larger is a PASSPHRASE". But that's just a guess on my
>part.

Not so that RACF will know, but so the application calling RACF will know. The 
application needs to know whether the user entered a password or password 
phrase so it can indicate that to RACF. (And, I suppose, so the application 
developers can decide when/whether to support password phrases.)

Additionally, password phrases get some strength from an increased number of 
characters supported, but primarily from increased length. The initial 
implementation required at least 14 characters for that reason, unless the 
installation wanted to provide an exit overriding that to a smaller value, 9 to 
13.

-- 
Walt

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

Re: How to grant access to CONSPROF

[Walt Farrell]

On Wed, 13 Mar 2019 11:39:30 -0700, Lizette Koehler  
wrote:

>Dear List -
>
>I am trying to run a batch REXX that issues CONSPROF or CONSOLE commands.
>
>I have set up everything in IKJTSO00 for CONSOLE, I have updated the RACF
>TSOAUTH for the ID issuing the commands
>
>The process will VARY OFFLINE and VARY ONLINE Dasd volumes
>
>Yet I am still getting
>
>IKJ55353I THE CONSPROF COMMAND HAS TERMINATED.+
>IKJ55353I USER USER001 DOES NOT HAVE CONSOLE COMMAND AUTHORITY.
>
>Any other places to check?

Have you verified that the user has a TSO segment? If it doesn't, I have a 
vague memory that you would need some TSO/E exit in order to authorize CONSOLE 
authority.

-- 
Walt

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

Re: RACF: Limiting update-authorization of a file to a particular application

[Walt Farrell]

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 lucky and can maintain a clean TSO/E environment from the 
start, up until after that application runs.

-- 
Walt

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

Re: RACF: Limiting update-authorization of a file to a particular application

[Walt Farrell]

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, so it 
has a clean TSO/E environment. And you program will not be able to use ISPF.

Or, you need to use a technique like UNIX System Services fork() to invoke part 
of your program in a separate, communicating address space that will run only 
the I/O services you need and pass data back and forth using UNIX services. 

Or you need to design some other form of client/server address space.

(Strictly speaking, if you have properly defined the PROGRAM ** profile and 
everything the user needs to run is coming from a program-controlled library, 
then you might find that the user's environment remains clean, and you don't 
need the TSOEXEC. But many TSO users run their own stuff, or things that you 
haven't inspected and "blessed" by defining them in PROGRAM **, and so most TSO 
environments (in my experience) become dirty and need either a logoff/logon or 
use of TSOEXEC to allow Program Access to Data Sets to work.)

-- 
Walt

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

Re: RACF: Limiting update-authorization of a file to a particular application

[Walt Farrell]

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 
>attaching the authorized task. There is no provision for running authorized 
>and 
>unauthorized code in parallel.

More correctly, The TMP sets the current task structure nondispatchable before 
attaching the new parallel task. The new task does not need to be an APF 
authorized one; either authorized or unauthorized code can run in the parallel 
TMP.

You're right that, because of the nondispatchability that is required for 
System Integrity, the code in the older TCBs is not actively running once the 
new TCB structure is created, and it does not resume until the new TCB 
structure has ended.

-- 
Walt

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

Re: RACF: Limiting update-authorization of a file to a particular application

[Walt Farrell]

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?

No. Your only good approach for doing this under TSO/E, if you're having 
problems with a dirty environment, is to TSOEXEC CALL your COBOL program, and 
have it run entirely isolated in the parallel TMP. You will, though, still need 
to make sure you have a properly constructed PROGRAM ** profile to ensure that 
the parallel TMP stays clean.

Of course, a multiple address space environment, perhaps one created using the 
UNIX System Services fork() operation could also work. That's one variation of 
the approach that Shmuel suggested.

-- 
Walt

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

Re: RACF: Limiting update-authorization of a file to a particular application

[Walt Farrell]

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 following error message just after the COBOL I/O routine is called by
>the subtask::
>
>ICH418I CONDITIONAL ACCESS LIST FOR DATA SET output.dataset  DID NOT GRANT
>AUTHORITY TO PROGRAM(S): EXEC CALL EXEC CALL
>
>This despite the fact that the COBOL I/O routine is executing under a
>separate subtask.

Again, subtasking does not provide the isolation you need. The parallel 
environment created by TSOEXEC (or by IKJEFTSR) is needed if you were having 
problems with a dirty TSO environment.

Your problem with EXEC and CALL is probably that you did not define PROGRAM ** 
properly.

And if you're going to be using a separately loaded I/O routine, as opposed to 
something built into your program, you'll probably want to use Enhanced Program 
Control (again, please read that section of the RACF Security Administrators 
Guide), which provides better security and restricts access to the main load 
module that you expect the users to execute.

-- 
Walt

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

Re: RACF: Limiting update-authorization of a file to a particular application

[Walt Farrell]

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 parallel isolated environment for RACF).

I did not say that. 

I said that you could use the TSOEXEC command to create a clean parallel 
environment. I also said that you still need to define PROGRAM ** with all the 
suggested libraries (from the Program Control documentation) in its ADDMEM 
list. That would include libraries like SYS1.LINKLIB and SYS1.CMDLIB but many 
more, too.

There is no substitute for carefully reading the Program Control and Program 
Access to Data Sets (PADS) sections of the RACF Security Administrators Guide. 
They describe the methods that can work, and (in detail) the requirements you 
must satisfy in order for PADS to work.

-- 
Walt

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

Re: How many asterisks to change a lightbulb?

[Walt Farrell]

On Mon, 4 Mar 2019 16:53:24 +, Jesse 1 Robinson  
wrote:

>On two different RACF plexes, we have these two profiles in the SDSF class:
>
>ISFCMD.ODSP.* (G)
>ISFCMD.ODSP.** (G)
>
>I'm confounded to explain the difference between one or two asterisks. Help?

The two differences:
(1) ISFCMD.ODSP.** will protect ISFCMD.ODSP, if that resource exists, bt 
ISFCMD.ODSP.* won't.

(2) When both exist, ISFCMD.ODSP.* will (if I remember correctly) be found 
first by RACF, and will supercede any specifications in ISFCMD.ODSP.** if both 
profiles match the supplied resource name (but I may not remember correctly). 
I'm reasonably sure the RACF Security Administrators Guide discusses this, as I 
think I wrote that section of the book at some time.

Ideally, if only to avoid confusing the security administrators and/or 
auditors, one of those profiles should be deleted.

-- 
Walt

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

Re: RACF: Limiting update-authorization of a file to a particular application

[Walt Farrell]

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 / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF: Limiting update-authorization of a file to a particular application

[Walt Farrell]

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 original environment is dirty. You still need to have PROGRAM **  
setup as documented, though, or that parallel environment might become dirty 
before the program you're CALLing gets control.

>Would specifying TASKLIB further ensure that only those modules
>loaded/linked/attached from the TASKLIB library need be RACF-authorized?

I'm not sure where you'd specify that TASKLIB. Of course, "CALL dsn(member)" 
sets up dsn as a TASKLIB for the task that member runs in, but other than that 
I'd need more details to answer your question.

The difficulty of using TSOEXEC, though, is that the program you call can't 
interact with ISPF at all, and that is critical for some programs. For others, 
it won't matter.

Also, setup will be easier if you enable Enhanced Program Control, as well as 
more secure, especially when using programming languages where functions are 
provided by dynamically loaded subroutines. Again, details in the RACF Security 
Administrators Guide.

-- 
Walt

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

Re: RACF: Limiting update-authorization of a file to a particular application

[Walt Farrell]

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 IKJEFT00

Unless the program is linkedited with AC(1) and needs to run authorized (most 
COBOL programs don't) I don't see a reason to put it in AUTHPGM.

You will likely run into problems in a TSO environment with the environment 
being marked dirty, as you noted.

Your best hope to avoid that is to make sure you've followed the instructions 
in the RACF Security Administrators Guide about defining the PROGRAM ** profie 
and all the libraries that you should specify for its ADDMEM operand. Make sure 
you use the specified UACC value, too.

If that doesn't work, then your next approach would be to try TSOEXEC CALL ... 
to invoke the program.

Really, all of this is explained in the Security Administrators Guide in the 
sections on Program Control and Program Access to Data (PADS), along with some 
examples and recommendations. As getting this working under TSO is very 
difficult, my best recommendation is to read those sections and follow the 
instructions exactly.

-- 
Walt

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

Re: What is the bit that causes the bypassing of dataset ENQ

[Walt Farrell]

On Mon, 11 Feb 2019 09:06:21 -0800, Charles Mills  wrote:

>I did not recall the exact operation of the bit flag. If I'd recalled that it 
>was an SVC 99 flag rather than some sort of global flag I might well have 
>found it myself.
>
>Why criticize people for asking a question? If they knew the answer they would 
>not have to ask the question -- 'tis true.
>

Just pointing out that providing as much info as possible helps generate 
correct answers. It doesn't matter if it was an SVC 99 flag, the important 
aspect was that the realm of your question was "when I do a dynamic 
allocation". There's also a flag for JCL-based allocation (that will also work 
for dynamic allocation) but operates differently, and is located elsewhere 
(PPT, to be specific).

Something like PPTNODSI (No DataSet Integrity), as I recall. For that one, the 
ENQ is first obtained, to ensure the dataset is indeed not being used in some 
conflicting way, and then released.

-- 
Walt

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

Re: What is the bit that causes the bypassing of dataset ENQ

[Walt Farrell]

On Sun, 10 Feb 2019 14:08:15 -0800, Charles Mills  wrote:

>A kind soul offline points out S99NORES.
>
>(No wonder I couldn't find it in the TCB.)

It also would have helped if you'd said you were interested in -dynamic- data 
set allocation, rather than simply data set allocation. It changes the answer.

-- 
Walt

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

Re: REXX syscalls and the dirty bit

[Walt Farrell]

On Thu, 24 Jan 2019 15:25:45 +, Steve Austin  
wrote:

>Hi, I'm using the 'shmat' syscall to attach a shared memory object, but using 
>the REXX storage function to alter it causes the dirty bit to be set. Any idea 
>why this is or how to prevent it?

As Ed said, because you're loading something that's not defined as PROGRAM 
controlled. For a start, make sure you've followed the directions in the RACF 
Security Administrators Guide for libraries that should be part of the PROGRAM 
** (or possibly, but less ideally, PROGRAM *) definition.

-- 
Walt

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

Re: Code vulnerability

[Walt Farrell]

On Sat, 8 Dec 2018 21:09:42 +0200, Binyamin Dissen  
wrote:

>I don't believe this tool would be appropriate for the OP as it detects system
>objects (for the lack of a better term) that allow inappropriate privilege
>elevation or storage access. Application code would not benefit from this
>tool.

You may be right, I don't think the OP has told us yet what kind of 
applications he's talking about, and I recall at least one vendor having 
previously mentioned using COBOL and HLASM for authorized STC code.

-- 
Walt

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

Re: Recommended method for accessing secondary access spaces

[Walt Farrell]

On Sun, 11 Nov 2018 09:39:31 -0500, Joseph Reichman  
wrote:

>on second there maybe another way of getting the
>information besides going into XMEM
>

There is another way, already mentioned in this thread: do all your 
"cross-memory" data gathering by scheduling SRBs into the other address spaces.

-- 
Walt

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

Re: Profiles specific to user

[Walt Farrell]

On Sat, 3 Nov 2018 15:00:01 -0500, Mike Cairns  wrote:

>Unfortunately the SEARCH command only applies to the user executing the 
>command.  Returning the profiles that *you*, the executing user, have access 
>to.  I think what Vignesh is asking for is a list of the profiles for a given 
>user when asking the question as an administrator.

I think you're forgetting the USER(userID) paramater on SEARCH, Mike:


USER(userid)
Specifies that RACF is to list the profiles that the specified user has 
access to (READ authority or higher, or owner) for the class you specify on the 
CLASS operand. RACF lists only those profiles that the specified owner is 
allowed to see. 


Nonetheless, I agree with you that using IRRDBU00 is a better approach, as 
SEARCH does not tell you -what- access the user has, nor -why- he has it. 
Generating a report based on IRRDBU00 output can tell you both of those, though 
you do need to perform the additional processing to include accesses based on 
the user's groups and UACC.

-- 
Walt

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

Re: ASCB scan and user-id...

[Walt Farrell]

On Sun, 16 Sep 2018 17:06:53 +0300, ITschak Mugzach  wrote:

>I do understand it, but it is interesting that  same blocks in different
>address spaces maps to same address spaces. It is clear why, it is always
>the same order of build, but still interesting.

Unless it's changed in the past few years, you'll find that the top few TCBs in 
each address space tend to be at the same addresses across address spaces, too. 
And the address space ACEE also is also commonly at the same address in each 
address space.

We had to design an interesting set of test cases when implementing some 
cross-memory functions in RACF to ensure that we were looking at the proper 
ASXB and proper TCB in all cases. It's very easy to end up looking at an ASXB 
or TCB or ACEE from Primary instead of Home if you're not careful :)

-- 
Walt

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

Re: Spectre/Meltdown APAR - OA54807

[Walt Farrell]

On Thu, 13 Sep 2018 09:21:39 -0700, Charles Mills  wrote:

>I do think IBM needs to somehow better accommodate ISVs. My understanding is 
>that "you have to own a real mainframe" to get access to the security 
>portal. Thus ISVs who own only zPDTs or who rent time at Dallas do not 
>qualify. 

I am not certain that having access to the portal would help you very much 
here. Unless things have changed significantly in the 7 years since  I left 
IBM, having access to the portal allowed users to find out that a Security or 
Integrity problem existed but did not give them any real details about the 
nature of the problem. Most IBMers couldn't even get those details, unless they 
were directly involved in resolving the problem.

As you're a vendor, I would expect IBM to notify you directly of any changes 
that they expected to affect you, just as they do (or did, when I was there) 
when making interface changes.

Some things have probably changed since then, but I would be surprised if IBM 
has started making more information available _to anyone_ in this area.

-- 
Walt

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

Re: General RACF question for Walt

[Walt Farrell]

On Mon, 6 Aug 2018 11:13:49 +, Blake, Daniel J [CTR]  
wrote:

>Years ago I was called to assist two different customers who both screwed up 
>the only Special userid.  In both cases I was able to switch to the IBM 
>supplied RACF data bases that came with a ServerPac.  Logged in with IBMUSER, 
>switched back and reset the SPECIAL userid.
>
>This was many years ago and I don't have a RACF protected system to play on.  
>Is this option still available?

It's hard to say whether that would work. For one thing, without an IPL you can 
only switch to a database of the same name as the one(s) you're already using. 

Every shop should have procedures in place for handling a situation like this 
without an IPL, and should also have additional procedures in place to IPL a 
"one-pack" recovery system in case their normal recovery procedures don't work 
for some reason.

A few common procedures that can help without an IPL:
(1) The ability for someone with SPECIAL to logon to an MVS operator console 
and issue RACF commands.
(2) An STC with SPECIAL that will issue an ALTUSER RESUME for one or more of 
the SPECIAL users.
(3) The ability for someone with SPECIAL to logon to TSO without using a 
session manager.

There are others, but those are easy. They do need to be setup in advance and 
tested regularly, along with recovery procedures for other critical system 
components (no JES, no catalog, etc.).

-- 
Walt

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

Re: RACF Special User Revoked System

[Walt Farrell]

On Sat, 4 Aug 2018 19:41:03 +0300, saurabh khandelwal 
 wrote:

>Thanks for reply.
>
>Special user is getting  below message
>
>IKJ5644I TSOLOGON RECONNECT REJECT - USER ACCESS REVOKED BY RACF
>
>and any other TSO user getting
>
>IKJ56425I  LOGON REJECTED, RACF TEMPORARILY REVOKING USER  access
>IKJ56418I CONTACT YOUR TSO ADMINISTRATOR

If _all_ other TSO users are getting that message, the most common cause I can 
think of is that you set your system time/date incorrectly, probably far into 
the future.

>
>I dont see any WTOR message for revoking or any such message for speical
>user and notbody else replied on any such WTOR.
>
>What i remember is, until this speical user is able to login or we get WTOR
>and reply , nobody else will be able to login to system even any other
>special user also .

In general that is not true. There are specific cases where it might be true. 
For example, if a SPECIAL user entered too many incorrect passwords while 
logging onto CICS then all logons to that CICS region might be affected. But 
all logons to TSO should not be affected _unless_ all logons go through some 
kind of terminal manager application which single-threads logons. In that case 
the solution is to logon some other SPECIAL user without using that terminal 
manager.

As others have recommended you should contact the IBM for assistance.

-- 
Walt

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

Re: Security bypass on key 0 / sup state VSAM OPEN was Re: A curiosity Question

[Walt Farrell]

On Sat, 28 Jul 2018 12:00:51 -0300, Clark Morris  wrote:

>[Default] On 27 Jul 2018 17:41:11 -0700, in bit.listserv.ibm-main
>rob.schr...@gmail.com (Rob Schramm) wrote:
>
>>I am not sure.. They out those extended checks with smf 82's.. and put some
>>use parameters in the asymuse.
>>
>>I don't like bypassing security calls.. it's just a slippery slope to
>>bypassing all of it.
>
>Why should OPEN security checking be bypassed for VSAM and no other
>access method in key 0 / supervisor state.

As far as I know only the VSAM designers who made that decision decades ago 
would know. My guess: some system component that could not tolerate the check 
(at that time probably for passwords, via an operator prompt) could not 
tolerate the interruption, so they decided to bypass the security check. Also, 
there is (or was) very little usage of OPEN for VSAM files by supervisor state 
or key 0 programs.

I found out about it many years ago while working on a customer problem report 
while I was in RACF Development. At that time it was undocumented. I recall 
that the VSAM team determined that behavior to be so old and ingrained to the 
processing that it could not be changed safely, for compatibility reasons if I 
remember correctly. But I did convince them it needed to be documented.

-- 
Walt

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

Re: A curiosity Question

[Walt Farrell]

On Fri, 27 Jul 2018 16:19:31 -0400, Rob Schramm  wrote:

>You would think that.. but what about the pervasive encryption?  Wouldn't
>ICSF with CHECKAUTH makes sure the key 0 user was authorized for the crypt
>key and possibly checked for use for the data set?

No, I would not expect ICSF to be involved with the data set checks at all. 
With the encryption you need to have access to the crypto data, and to the data 
set, but nothing says that ICSF is involved with checking both. Access to the 
data set can be granted by any of the usual mechanisms, as far as I know.

-- 
Walt

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

Re: A curiosity Question

[Walt Farrell]

On Thu, 26 Jul 2018 22:05:08 -0400, Rob Schramm  wrote:

>How does that interact with ICSF CHECKAUTH that forces security checks for
>authorized address spaces?

There is no interaction, because you're mixing up different kinds of checks. 
We've been talking about OPENing VSAM clusters, but you've just asked about 
ICSF doing checks that are related to crypto requests, not OPEN. Totally 
different beasts.

-- 
Walt

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

Re: A curiosity Question

[Walt Farrell]

On Thu, 26 Jul 2018 20:56:07 -0500, Paul Gilmartin  wrote:

>On Thu, 26 Jul 2018 22:13:01 -0300, Clark Morris wrote:
> ...
>>Why would they exclude only VSAM from checking?  Is it because of Page
>>Datasets or some other reason?  Are there other ways of bypassing or
>>ignoring checking for supervisor and key zero code?
>>
>My conjecture is that the VSAM address space itself performs the needed check.
>

No, there is no security check done when a supervisor state or key 0 program 
OPENs a VSAM cluster. If any checking is deemed necessary, it is up to the 
caller to perform it by issuing their own RACROUTE or RACHECK.

-- 
Walt

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

Re: A curiosity Question

[Walt Farrell]

On Thu, 26 Jul 2018 09:54:48 -0500, Tom Marchant  
wrote:

>On Thu, 26 Jul 2018 07:50:04 -0500, Walt Farrell wrote:
>
>>On Tue, 24 Jul 2018 15:08:51 +, Seymour J Metz wrote:
>>
>>>Neither APF authorization nor supervisor state suspend normal SAF processing 
>>>for, e.g., OPEN. If you know of a privileged application  >that bypasses 
>>>normal resource controls and does not require SAF authorization before doing 
>>>so, then it's APAR time.
>>
>>I believe there is one exception to that, unless the behavior has been 
>>changed in the past few years: as I recall, OPEN for a 
>>VSAM file will bypass security checking if the issuer of OPEN is running in 
>>supervisor state. I think it's documented (briefly) 
>>deep in some manual, but I forget which one.
>
>See the last sentence:
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/ods.htm
>
>"Note: RACF protection supersedes password protection for a data set. RACF 
>checking is bypassed for a caller that is in supervisor state or key 0."
>

Thanks, Tom. And, note, for those who may not follow the link, that that 
statement is for VSAM only.

-- 
Walt

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

Re: A curiosity Question

[Walt Farrell]

On Tue, 24 Jul 2018 15:08:51 +, Seymour J Metz  wrote:

>Neither APF authorization nor supervisor state suspend normal SAF processing 
>for, e.g., OPEN. If you know of a privileged application  >that bypasses 
>normal resource controls and does not require SAF authorization before doing 
>so, then it's APAR time.

I believe there is one exception to that, unless the behavior has been changed 
in the past few years: as I recall, OPEN for a VSAM file will bypass security 
checking if the issuer of OPEN is running in supervisor state. I think it's 
documented (briefly) deep in some manual, but I forget which one.

-- 
Walt

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

Re: TSO TEST breakpoint subcommand call either looping or not being executed

[Walt Farrell]

On Mon, 9 Jul 2018 08:29:09 -0400, Joseph Reichman  
wrote:

>I have gotten the following code to work (with the help of Binyamin) as I will 
>list below but the problem is it is only being executed once and I am looping 
>thru a number of records
>Seems like when I get to DUMBRK OFF +4; GO +4 it is removed and I would like 
>to process it for the next iteration of the code
>   
>LOAD 'MYTEST.LOAD(TESTPROG)'
> 
> GETMAIN 24 SP(0) LOC(BELOW) EQUATE(RGESVE)  
> GETMAIN 2 SP(0) LOC (BELOW) EQUATE(DUMBRK)
>
> DUMBRK = X'0700'
>
>AT +4( AT DUMBRK (COPY  RGESVE 14R L(16); OFF +4; GO +4): COPY 14 RGESVE 
>L(16); RGEAVE+10=C'PARM1'; CALL TESTPROG.TESTPROG PARM(RGESVE) RETURN(DUMBRK)) 
>TITLE('BREAK AT +4')

Suggestion:
(1) Increase the size of DUMBRK so it can include the instruction located at +4 
in TESTPROG, plus another x'0700'. Set DUMBRK to x'0700', then the instruction 
from TESTPROG, then another x'0700'. Assuming that TESTPROG instuction is 4 
bytes in length, DUMBRK would then be 8 bytes in length.

(2) For the breakpoints, something like the following (untested):

AT +4 (COPY 14R RGESVE L(16); RGEAVE+10=C'PARM1'; CALL TESTPROG.TESTPROG 
PARM(RGESVE) RETURN(DUMBRK)) TITLE('BREAK AT +4'))
AT DUMBRK (COPY  RGESVE 14R L(16); GO DUMBRK+2)
AT DUMBRK+6 (GO +8)

-- 
Walt

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

Re: Running TSO TEST in Background

[Walt Farrell]

On Fri, 6 Jul 2018 13:38:45 -0400, Joseph Reichman  
wrote:

>Would any one know if you can run TSO TEST as a background Job on either
>IKJEFTSOEV or IKJEFT01

I would expect it to work under IKJEFT01 (and I vaguely recall doing that in 
the distant past), but probably it would not work in an environment established 
by  IKJTSOEV.

-- 
Walt

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

Re: Linklist and APF

[Walt Farrell]

On Thu, 5 Jul 2018 17:18:24 +0200, R.S.  wrote:

>I have job with the following steplib:
>
>//STEPLIB DD DISP=SHR,DSN=HLQ.LNKLST.LIB1
>// DD DISP=SHR,DSN=HLQ.LNKLST.LIB2
>// DD DISP=SHR,DSN=HLQ.NONLNK.LIB3
>
>LIB1, and LIB2 reside in LNKLST, but not on APF.
>LIB3 is not on LNKLST, but is APF-authorized.
>
>The job works when all 3 libraries are in steplib concatenation. When I
>remove LIB1 and LIB2 it doesn't work. Is it because lack of explicit APF
>authirization?
>LNKLST is authorized by IEASYS default entry.

It would help to know what you mean by "works" and "doesn't work". 

But for a start, remember that LNKAUTH=LNKLST means that the libraries in the 
link list are all authorized *when they are accessed as part of the link list*. 
Therefore, your STEPLIB concatenation is *not* APF-authorized, because it 
contains LIB1 and LIB2 which are not APF-authorized in your usage.

My guess about what you mean by "doesn't work" is that once the job step is 
running APF-authorized (which will happen when you remove LIB1 and LIB2 from 
STEPLIB) you're getting an S0C4 abend because some program you're running 
claims to be RENT but isn't. When run APF-authorized it's loaded into protected 
storage, and when it tries to store into itself it gets the S0C4.

-- 
Walt

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

Re: Eternal WAIT on un-waited ECB

[Walt Farrell]

On Mon, 25 Jun 2018 11:22:51 -0700, Charles Mills  wrote:

>Well, it's not a "problem" (FSVO "problem") but in an example that is
>supposed to show the fast way of doing things, one might avoid slower
>instructions, such as storage literal references, when alternatives like
>TMLH and LLILF are now available.

Even with the older instructions it will be faster than doing a real POST :)

(And if an application's performance characteristics are such that the 
difference in a few instructions in a fast-POST implementation are going to 
matter, should it really be using WAIT/POST, or something else altogether?)

-- 
Walt

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

Re: Is TCBSENV propagated to child TCB by ATTACHX

[Walt Farrell]

On Fri, 22 Jun 2018 09:43:15 -0500, John McKown  
wrote:

>This is strictly a curiosity question. Suppose for some unspecified &
>irrelevant to this discussion that my code is running under a TCB which has
>a non-zero TCBSENV value. If my code were to do an ATTACHX to create a
>subtask, would the new TCB have the same TCBSENV as my code, or would it be
>zero? I did RTFM but did not see anything that addresses this. And an IBM
>KC search got so many hits that I was completely befuddled.

No, in the general case ATTACH/X does not propagate TCBSENV from parent to 
child.

There is one exception I recall, but I leave research on the details (and 
proper terminology) to someone else.

I believe that WLM provides functions that allow requestors to schedule work to 
a server address space, and cooperating worker address spaces to pull requests 
off of the server queue for processing. Those WLM services also capture the 
security credentials for the requestor. When the worker pulls a request the 
system instantiates a copy of the requestor's ACEE for the worker so the 
request runs with the requestor's security credentials.

In that environment (and only in that environment, as far as I know) if the 
code running in the worker does an ATTACH/X, TCBSENV _is_ propagated to the 
daughter TCB.

-- 
Walt

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

Re: 2 possible RFE --- ISPF & SDSF.

[Walt Farrell]

On Fri, 22 Jun 2018 15:02:35 -0400, Steve Smith  wrote:

>I'll grant you have a point... but I thought the national characters were
>defined as x'5B', x'7B', and x'7C', regardless of how displayed.
>

Correct. The hex value is the important part. Depending on your codepage and/or 
keyboard it may look like a completely different character. But if you have 
something that not code-page aware and expects a $ (dollar sign) then it's 
looking for x'5B'. You have to type whatever character on your keyboard will 
give you that hex value.

-- 
Walt

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

Re: RACF protection of a volume

[Walt Farrell]

On Mon, 4 Jun 2018 17:27:25 -0500, Todd Burrell  wrote:

>Hopefully this is not a stupid question - but is it possibly via RACF (maybe 
>with DASDVOL) to allow a particular system to have only read access to a DASD 
>volume?  We have a need to possibly vary some devices onto a system in one 
>plex while it is being updated on another plex, so we would like to ensure the 
>one system cannot update the volume.

General.answer: No, it's not possible.

Limited situation answer: Yes, if 
(a) you're willing to write some RACF exits, and

(b) only want protection from data set creation/deletion and update via normal 
means (JCL, dynamic allocation, OPEN, etc.) via normal users, and 

(c) don't care what your system programmers and/or storage administrators might 
do either with authorities like OPERATIONS or via other means such as ADRDSSU, 
ICKDSF, etc.

-- 
Walt

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

Re: UserKEY CSA/Dataspace scope=common Remdiation

[Walt Farrell]

On Tue, 15 May 2018 16:53:33 +, Jousma, David  wrote:

>Ok, quick eye-ball verification from the guru's that are better ASM programmer 
>than I...
>
>SMF30 RAXFLAGS is kicking out the a  module for which I selectively pulled out 
>the DSPSERV code for allocating USERKEY SCOPE=COMMON Data space.   Is it 
>possible that this line "DSPSERV  DCA(*+4+X'8000')" is what is setting 
>the storage key just prior to execution?  i.e. KEY 8?  I didn't create the 
>code, I'm just trying to understand it.
>
> MODESET MODE=SUP  SET TO SUPERVISOR STATE
> L R15,DSPSERV INSURE 31 BIT MODE
> BSM   0,R15   SET 31 BIT MODE
>DSPSERV  DCA(*+4+X'8000')
>*
> DSPSERV CREATE,   CREATE A DATA SPACE
>   STOKEN=DSPSTOKN,PUT STOKEN HERE
>   NAME=DSPNAME,   USE THIS NAME
>   ORIGIN=DSPORIGN,PLACE ORIGIN ADDRESS HERE
>   SCOPE=COMMON,   COMMON DATA SPACE
>   BLOCKS=(DSPBLCKS,DSPBLCKS)  THIS MAX AND INITIAL
>*
> STR15,RETCODE SAVE THE RETURN CODE
> STR0,REASCODE SAVE THE REASON CODE
> MODESET MODE=PROB SET TO PROBLEM PROGRAM STATE
>
>
>Alternatively, I know the DataSpace names that are being allocated from a D 
>A,stcname.Again, this is territory I don't tread into often, but is there 
>an 
>easy way to determine the storage key of them?

What key is your program running in? The default for DSPSERV CREATE (as I read 
the manual) is CALLERKEY, so if it's running in key 8 that would be your 
problem.

-- 
Walt

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

Re: GETMAIN LOC=32

[Walt Farrell]

On Tue, 15 May 2018 12:10:46 -0500, Paul Edwards  wrote:

>On Tue, 15 May 2018 11:57:55 -0500, Tom Marchant  
>wrote:
>
>>>There are multiple ways of guaranteeing 0. The
>>>best is IBM guaranteeing it on entry to a program,
>>>as another RFE. In the single test that I requested,
>>>the high bits seem to be 0 already. I just want to
>>>formalize that.
>>
>>IBM cannot guarantee that. A basic principle in MVS is that any program 
>>can be called by another program. You don't know how a program that 
>>calls you might use the 64-bit registers.
>
>I don't see anything wrong with "LINK" being
>updated to save the high 32-bits (or more,
>in future) of registers and then zeroing them so
>that called 32-bit programs can run in AM64 or
>AM128 or AM256. Who will be affected? "LINK"
>can be updated to accept an AM64 caller at the
>same time.

And so it grows. 

You want GETMAIN updated (though the key z/OS designers have already said that 
won't happen). You probably want z/OS storage layout changed, so you can 
acquire more storage. And now you want LINK changed to manage registers 
differently. 

What additional changes will you need next in z/OS in order to support this 
addressing mode that IBM hasn't seen a need for?

How are you planning to justify all this work to IBM? How much additional money 
in terms of hardware purchases or software purchases will the writers of AM(32) 
modules be spending with IBM, to justify all the development and testing 
resources that your growing list of changes will require?

-- 
Walt

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

Re: GETMAIN LOC=32

[Walt Farrell]

On Mon, 7 May 2018 09:00:37 -0500, Paul Edwards  wrote:

>I just want z/OS to match MVS/380,
>and there is nothing technically preventing
>that from happening.

Nothing, except all the z/OS changes that you haven't considered, and all the 
application changes they might imply for existing applications that really 
don't care about 32-bit capability.

One problem was mentioned earlier in this thread: ELSQA, EPVT, ECSA, ELPA, and 
ENUC will prevent you getting the 3GiB that you want, because they're sitting 
in the way today. So, in addition to the "simple" changes you want, z/OS would 
also have to change its storage layout. I can't predict what parts of the 
system that would affect and how complex it would be, or what applications it 
might affect.

I'm sure there are more.

-- 
Walt

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

Re: AC(1)

[Walt Farrell]

On Mon, 30 Apr 2018 16:54:22 -0700, Charles Mills  wrote:

>Do you want to query AC(1) specifically or whether you are running
>authorized, which requires AC(1) plus an all-APF-authorized STEPLIB
>concatenation?

No, running authorized does not (necessarily) require AC(1). 

Assuming consider only APF-authorization, and not forms like system key or 
supervisor state, and ignoring situations like TSO and perhaps some aspects of 
z/OS UNIX, it requires that the first program executed in the jobstep had 
AC(1). But subsequent programs run by that program don't need (and shouldn't 
have, in general) AC(1). They just need to come from an APF-authorized library 
or concatenation. So AC(1) is required only if you're the first program that 
was executed in the jobstep.

But it's a good question, as merely wanting to know if you were linked AC(1) 
seems not terribly useful to a running program.

-- 
Walt

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