Re: ATTACHX/STIMERM WAIT=YES

[Tony Harminc]

On Mon, 13 Nov 2023 at 19:37, Paul Schuster  wrote:

> How to handle this situation: task ‘A’ attaches a subtask, task ‘B’.
>
> The ‘B’ task issues a STIMERM WAIT=YES
>
> Task ‘A’ terminates, but gets the A03 abend since task ‘B’ still active.
>
> How can task ‘A’ communicate to the subtask ‘B’ that it (task ‘B’) needs
> to terminate?  Task ‘B’ is in the STIMERM wait, so it can’t do anything.
>

The typical approach is to not use WAIT on the STIMERM in Task B, but
rather specify a local ECB to be POSTed. Then do your own WAIT, specifying
both that ECB and also an ECB that Task A passes to Task B as an argument
on the ATTACH[X]. When Task A wants to shut things down, it POSTs the ECB
it passed to B, and then in turn *it* WAITs on the other ECB that you
specified on the ATTACH with ECB=. When Task B awakes from its WAIT, it
checks which ECB was posted. If it's the STIMER one, it does whatever it
does for that, and goes back and re-issues the STIMERM and the WAIT. If
it's the one saying "A says to shut down", B cleans up and returns to the
system, which then POSTs the ECB that A put on the ATTACH.

This assumes that in your description Task A *intends* to shut down B and
then itself. If Task A instead terminates unexpectedly, then you need to
figure out what you *want* it to do. You could put ESTAI= on the ATTACH,
and catch B's abend there. But if A abended in the first place...

This isn't really as complex as I'm making it sound with a poorly organized
description. Just don't do that WAIT on the STIMERM.

Tony H.

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

Re: ATTACHX/STIMERM WAIT=YES

[Steve Thompson]

Just off the top of my head from having a similar issue a few 
years ago, you may need to be watching two ECBs (EVENTS). But I'm 
not sure that the STIMERM won't cause a squawk when you have the 
task end.



And I think you will have to pass the address of the ECB you will 
POST for termination to the Attached task. Otherwise, you might 
be able to do a  CALLRTM to terminate the subtask. Now, the 
subtask will need an error recovery routine to hide the fact that 
you just term'ed it.


Here is what the macro contains relative to this:

THE STIMERM MACRO ALLOWS THE ISSUER TO SET, TEST OR CANCEL
UP TO 16 REAL TIME INTERVALS.  AT THE TIME THE INTERVAL IS
ESTABLISHED, THE CALLER MAY OPTIONALLY SPECIFY AN EXIT ROUTINE
TO BE GIVEN CONTROL ASYNCHRONOUSLY AFTER THE TIME INTERVAL
EXPIRES OR THAT EXECUTION OF THE CURRENT TASK IS TO BE
SUSPENDED.

AN ERROR EXIT MAY ALSO BE SPECIFIED WHICH MAY BE GIVEN CONTROL
IF THE STIMERM FUNCTION CANNOT BE PERFORMED.

Steve Thompson


On 11/13/2023 7:37 PM, Paul Schuster wrote:

How to handle this situation: task ‘A’ attaches a subtask, task ‘B’.

The ‘B’ task issues a STIMERM WAIT=YES

Task ‘A’ terminates, but gets the A03 abend since task ‘B’ still active.

How can task ‘A’ communicate to the subtask ‘B’ that it (task ‘B’) needs to 
terminate?  Task ‘B’ is in the STIMERM wait, so it can’t do anything.

I didn’t see this scenario documented in the Assembler Services Guide or the 
Assembler Services References.

Thank you.

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


--
Regards, Steve Thompson

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

Re: ATTACHX/STIMERM WAIT=YES

[Seymour J Metz]

DETACH? Or do you need something less disruptive?


-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Paul Schuster 
Sent: Monday, November 13, 2023 7:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ATTACHX/STIMERM WAIT=YES

How to handle this situation: task ‘A’ attaches a subtask, task ‘B’.

The ‘B’ task issues a STIMERM WAIT=YES

Task ‘A’ terminates, but gets the A03 abend since task ‘B’ still active.

How can task ‘A’ communicate to the subtask ‘B’ that it (task ‘B’) needs to 
terminate?  Task ‘B’ is in the STIMERM wait, so it can’t do anything.

I didn’t see this scenario documented in the Assembler Services Guide or the 
Assembler Services References.

Thank you.

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

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

ATTACHX/STIMERM WAIT=YES

[Paul Schuster]

How to handle this situation: task ‘A’ attaches a subtask, task ‘B’.

The ‘B’ task issues a STIMERM WAIT=YES 

Task ‘A’ terminates, but gets the A03 abend since task ‘B’ still active.

How can task ‘A’ communicate to the subtask ‘B’ that it (task ‘B’) needs to 
terminate?  Task ‘B’ is in the STIMERM wait, so it can’t do anything.

I didn’t see this scenario documented in the Assembler Services Guide or the 
Assembler Services References.

Thank you.

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

Re: UNIX "BLKSIZE"?

[Paul Gilmartin]

On Mon, 13 Nov 2023 19:09:26 -0500, Tony Harminc wrote:
>>
>> >>On Mon, 13 Nov 2023 01:10:14 -0600, Jon Perryman >> wrote:
>> >>z/OS Unix filesystems are linear datasets.
>
>Some are.
> 
Exceptions might be sockets, descriptors, pipes, and NFS.  And not all
UNIX files belong to filesystems.

>>No.  BLKSIZE is not ignored.
>>
I was envisioning unblocked RECFM (or BLKSIZE=LRECL) as achieving
the effect of setvbuf( ..., _IOLBF )


o {_IOLBF} shall cause input/output to be line buffered.

-- 
gil

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

Re: UNIX "BLKSIZE"?

[Tony Harminc]

On Mon, 13 Nov 2023 at 13:54, Jon Perryman  wrote:

> On Mon, 13 Nov 2023 09:11:19 -0600, Paul Gilmartin 
> wrote:
>
> >>On Mon, 13 Nov 2023 01:10:14 -0600, Jon Perryman 
> wrote:
> >>z/OS Unix filesystems are linear datasets.
>

Some are.

>No.  BLKSIZE is not ignored.
>
> Incorrect, BLKSIZE has no meaning for VSAM linear datasets. By definition,
> "All linear data set bytes are data bytes" which is how a Unix filesystem
> functions.
>

Not all z/OS UNIX filesystems are VSAM linear datasets, nor do such
datasets directly match the UNIX file semantics.

A Unix file is always 1 logical record. BLKSIZE has no meaning in this
> context. While BLKSIZE is stored in the DCB the subsystem ignores it. Any
> part of that logical record can be processed or in its entirety (e.g. read
> or write at offset 1000 for 100 bytes).
>
> > for BSAM it affects how many times the WRITE/CHECK is issued,
>
> This is conjecture because logic for BSAM communications to the Unix file
> subsystem is not made publicly. I suspect that CHECK is a simple BR14 but
> maybe IBM bypassed this logic. BSAM CHECK has no meaning because the
> subsystem will determine to do VSAM CHECK because it must remain compatible
> with UNIX. As for the WRITE, we don't know if every program write causes a
> transfer to the file subsystem or if BSAM buffers according to the BLKSIZE
> before sending to the subsystem. I'm not willing to venture a guess because
> there are pro's and con's to both methods.
>

I think you're muddling interface levels. I'd suggest a high-level read
through of the z/OS UNIX System Services File System Interface Reference.
There's a good introductory picture at
https://www.ibm.com/docs/en/zos/2.5.0?topic=overview-system-structure. Very
clearly the xSAM interfaces do not talk directly to an underlying VSAM
filestore, if there is one.

Tony H.

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

Re: UNIX "BLKSIZE"?

[Seymour J Metz]

While BLKSIZE has no meaning for linear data sets, it *does* have meaning for 
the BSAM compatibiliy interface.


-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of Jon 
Perryman 
Sent: Monday, November 13, 2023 1:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UNIX "BLKSIZE"?

On Mon, 13 Nov 2023 09:11:19 -0600, Paul Gilmartin  wrote:

>>On Mon, 13 Nov 2023 01:10:14 -0600, Jon Perryman  wrote:
>>z/OS Unix filesystems are linear datasets.

>No.  BLKSIZE is not ignored.

Incorrect, BLKSIZE has no meaning for VSAM linear datasets. By definition, "All 
linear data set bytes are data bytes" which is how a Unix filesystem functions.

> It is merged into the DCB by OPEN,
> or supplied by SDB if not otherwise specified.

A Unix file is always 1 logical record. BLKSIZE has no meaning in this context. 
While BLKSIZE is stored in the DCB the subsystem ignores it. Any part of that 
logical record can be processed or in its entirety (e.g. read or write at 
offset 1000 for 100 bytes).

> for BSAM it affects how many times the WRITE/CHECK is issued,

This is conjecture because logic for BSAM communications to the Unix file 
subsystem is not made publicly. I suspect that CHECK is a simple BR14 but maybe 
IBM bypassed this logic. BSAM CHECK has no meaning because the subsystem will 
determine to do VSAM CHECK because it must remain compatible with UNIX. As for 
the WRITE, we don't know if every program write causes a transfer to the file 
subsystem or if BSAM buffers according to the BLKSIZE before sending to the 
subsystem. I'm not willing to venture a guess because there are pro's and con's 
to both methods.

> and probably has some effect on performance for QSAM.

I'm guessing that performance benefit is insignificant. More important is the 
adverse effect of buffering by BSAM / QSAM. It violates the UNIX standard of 
concurrent writes to a file. Most people don't think about the impact of this 
logic which says you have a file open 20 times, the records will be interleaved 
according to the time the write occurred. Instead of immediately adding each 
record, BSAM / QSAM buffering would delay adding the records to the file 
causing them to be out of sequence. I simply can't see IBM enabling BSAM / QSAM 
buffering that would confuse Unix programmers, but I could be wrong.

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

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

Re: RACF, the FACILITY class, and z/XDC

[David Cole]

Hi Jon,

Thanks for your thoughts, but I'm not trying to 
decide if I should use FACILITY. I'm trying to 
decide how I should go about discontinuing using FACILITY.


Based on suggestions from others on this thread, 
I've made the decision to switch to using a class named XFACILIT.


[Switching will be tricky though. I don't want to 
leave existing customers high and dry, so I'll 
have to "dual path" (soft of). But I don't want 
to create security exposures by doing it wrong.]


Dave








At 11/13/2023 02:51 PM, Jon Perryman wrote:

On Mon, 13 Nov 2023 13:30:56 -0500, David Cole  wrote:

>so while creating a "$XDC" class perhaps might be "easy", to
>paraphrase Peter, why would I make a customer 
do that when I don't have to...

>
>So thank you to those who tipped me off about the XFACILIT. It sounds
>perfect for my needs.

Dave, as food for thought:

RACF FACILITY is a special class which needs 
special consideration in recommending it. For 
instance, ask yourself why the resource name is restricted to 39 characters.


If you choose to recommend FACILITY, you might 
need to document special considerations and 
include sections for each of the security 
products (e.g. RACF, ACF2 and Top-secret).


It's been a very long time for me, but I think 
these are in storage rules. Probably not a big 
deal if you only have a couple of rules but it's 
something you should consider. Additionally, I 
believe FACILITY requires a refresh in RACF. I 
can't remember about ACF2 and Top-secret. These are customer considerations.


If I remember correctly, RACF uses class numbers 
which has a limit. classes are associated to a 
number and mutliple classes can use the same 
number. It's not unusual for customers to 
combine classes into a single class but they 
must avoid resource name collisions. It's a good 
practice to uniquely identify your product in the resource name.


 I can't recall how ACF2 and Top-secret handle 
these situations. Maybe they have a facility to equate multiple RACF classes.


As an alternative to FACILITY, you might 
consider a class that is not special but exists 
at all. For example, I've had customers use the dataset class.


You may want to continue with class $XDC as your 
recommendation with alternatives. Equating 
classes can be useful. For instance, companies 
acquire other companies which means staff is 
dealing with multiple unique environments. It 
easier to manage XDC rules when class $XDC is 
specified although it has a different meaning in each environment.


I'm not suggesting you take this as advice but 
simply to make you aware of these points.


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


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

Re: RACF, the FACILITY class, and z/XDC

[Jon Perryman]

On Mon, 13 Nov 2023 13:30:56 -0500, David Cole  wrote:

>so while creating a "$XDC" class perhaps might be "easy", to
>paraphrase Peter, why would I make a customer do that when I don't have to...
>
>So thank you to those who tipped me off about the XFACILIT. It sounds
>perfect for my needs.

Dave, as food for thought:

RACF FACILITY is a special class which needs special consideration in 
recommending it. For instance, ask yourself why the resource name is restricted 
to 39 characters.

If you choose to recommend FACILITY, you might need to document special 
considerations and include sections for each of the security products (e.g. 
RACF, ACF2 and Top-secret).

It's been a very long time for me, but I think these are in storage rules. 
Probably not a big deal if you only have a couple of rules but it's something 
you should consider. Additionally, I believe FACILITY requires a refresh in 
RACF. I can't remember about ACF2 and Top-secret. These are customer 
considerations.

If I remember correctly, RACF uses class numbers which has a limit. classes are 
associated to a number and mutliple classes can use the same number. It's not 
unusual for customers to combine classes into a single class but they must 
avoid resource name collisions. It's a good practice to uniquely identify your 
product in the resource name.

 I can't recall how ACF2 and Top-secret handle these situations. Maybe they 
have a facility to equate multiple RACF classes.

As an alternative to FACILITY, you might consider a class that is not special 
but exists at all. For example, I've had customers use the dataset class. 

You may want to continue with class $XDC as your recommendation with 
alternatives. Equating classes can be useful. For instance, companies acquire 
other companies which means staff is dealing with multiple unique environments. 
It easier to manage XDC rules when class $XDC is specified although it has a 
different meaning in each environment.

I'm not suggesting you take this as advice but simply to make you aware of 
these points.

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

Re: UNIX "BLKSIZE"?

[Paul Gilmartin]

On Mon, 13 Nov 2023 12:54:31 -0600, Jon Perryman wrote:
>...
>> and probably has some effect on performance for QSAM.
>
>I'm guessing that performance benefit is insignificant. More important is the 
>adverse effect of buffering by BSAM / QSAM. It violates the UNIX standard of 
>concurrent writes to a file. Most people don't think about the impact of this 
>logic which says you have a file open 20 times, the records will be 
>interleaved according to the time the write occurred. Instead of immediately 
>adding each record, BSAM / QSAM buffering would delay adding the records to 
>the file causing them to be out of sequence. I simply can't see IBM enabling 
>BSAM / QSAM buffering that would confuse Unix programmers, but I could be 
>wrong.
>
I suppose part of the answer is here:


-The access method buffers writes beyond the buffering that your program 
sees. This means that after your program issues BSAM WRITE and CHECK, QSAM PUT 
with BUFNO=1 or a VSAM PUT, the data probably is not yet on the disk. If the 
file is not a FIFO, your program can issue the BSAM or QSAM SYNCDEV or CLOSE 
macro to force immediate writing. This interferes with good performance.

-- 
gil

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

Re: unable to access IPCS 64 bit storage using Storage map service

[Joseph Reichman]

Changing the length to =AD(100) did it thanks 

Adam 

> On Nov 13, 2023, at 1:04 PM, Joseph Reichman  wrote:
> 
> I’m using test to debug this thanks 
> 
>>> On Nov 13, 2023, at 11:28 AM, Adam Johanson 
>>> <031ca9d720a7-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>>> Joe wrote:
>>> I got a number of responses but I decided to use the post By Adam Johanson
>>> using storage map services below is my code
>> 
>>  It appears that I am now pot-committed to this thread, so here goes.
>> 
>> 
>> John P. wrote:
>>> My suggestion would be to start from a function use of ADPLSACC which can 
>>> be found at https://planetmvs.com/ipcs/ivxSName.txt
>> 
>>> Once you verify it's functioning correctly, start modifying it to access 64 
>>> bit storage. Without a source listing, it's hard to tell if everything is 
>>> initialized correctly.
>> 
>> ADPLSACC doesn't appear to work for accessing 64-bit storage, or at least I 
>> couldn't see how to get it to work. This is the reason I went with the 
>> Storage Map service and gave it as an example.
>> 
>> 
>> Joe, in your excerpts, these lines pop out:
>> 
>>>MVC   MAPAST,VIRTUAL#STORAGE Virtual storage address space 
>>>MVC   MAPAS2+2(2),ASID#  
>> 
>> It's not clear what VIRTUAL#STORAGE is, but following the example, MAPAST 
>> needs to be set to the ZZZASTCV EQUate for CPU/ASID type. Always better to 
>> use the provided EQUates.
>> 
>> Also, you're moving the ASID# into MAPAS2+2 and it's not clear that the 
>> first 2 bytes of MAPAS2 have been initialized to zeroes (I assume that it 
>> matters). The code doesn't explicitly initialize them, and the area doesn't 
>> appear to be populated by an "initialized" BLSRSASY area. I would suggest 
>> having an initialized BLSRSASY area in the constant-area of your program and 
>> copy this into your WORKAREA copy. Doing this sets several fields for you 
>> that you don't have to explicitly set yourself, chief among them being the 
>> ABITS=64 business.
>> 
>> And this line:
>> 
>>> MVC   MAPFLE,=A(100)
>> 
>> MAPFLE is 8 bytes.
>> 
>>  There might be other problems in this sample, but these are the initial 
>> ones I see. It might be good to either use a debugger or get a dump at the 
>> time of your ADPLSERV invocation and make sure that the areas that you're 
>> passing line up with what they're supposed to look like, using the 
>> expansions in the listing.
>> 
>> ===
>> Adam Johanson
>> Broadcom Mainframe Software Division
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: RACF, the FACILITY class, and z/XDC

[Binyamin Dissen]

On Mon, 13 Nov 2023 12:58:16 + Peter Relson  wrote:

:>Regardless of whether it is hard or easy, why would you
:>want to bother creating a new class when there is an
:>existing class (XFACILIT) that completely addresses the problem
:>(and thus would be easier for a customer)?

DEFAULTRC
OPERATIONS
Unexpected masked rules
More hands in the pot

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: UNIX "BLKSIZE"?

[Jon Perryman]

On Mon, 13 Nov 2023 09:11:19 -0600, Paul Gilmartin  wrote:

>>On Mon, 13 Nov 2023 01:10:14 -0600, Jon Perryman  wrote:
>>z/OS Unix filesystems are linear datasets. 

>No.  BLKSIZE is not ignored. 

Incorrect, BLKSIZE has no meaning for VSAM linear datasets. By definition, "All 
linear data set bytes are data bytes" which is how a Unix filesystem functions.

> It is merged into the DCB by OPEN, 
> or supplied by SDB if not otherwise specified. 

A Unix file is always 1 logical record. BLKSIZE has no meaning in this context. 
While BLKSIZE is stored in the DCB the subsystem ignores it. Any part of that 
logical record can be processed or in its entirety (e.g. read or write at 
offset 1000 for 100 bytes).   

> for BSAM it affects how many times the WRITE/CHECK is issued, 

This is conjecture because logic for BSAM communications to the Unix file 
subsystem is not made publicly. I suspect that CHECK is a simple BR14 but maybe 
IBM bypassed this logic. BSAM CHECK has no meaning because the subsystem will 
determine to do VSAM CHECK because it must remain compatible with UNIX. As for 
the WRITE, we don't know if every program write causes a transfer to the file 
subsystem or if BSAM buffers according to the BLKSIZE before sending to the 
subsystem. I'm not willing to venture a guess because there are pro's and con's 
to both methods. 

> and probably has some effect on performance for QSAM.

I'm guessing that performance benefit is insignificant. More important is the 
adverse effect of buffering by BSAM / QSAM. It violates the UNIX standard of 
concurrent writes to a file. Most people don't think about the impact of this 
logic which says you have a file open 20 times, the records will be interleaved 
according to the time the write occurred. Instead of immediately adding each 
record, BSAM / QSAM buffering would delay adding the records to the file 
causing them to be out of sequence. I simply can't see IBM enabling BSAM / QSAM 
buffering that would confuse Unix programmers, but I could be wrong.

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

RACF, the FACILITY class, and z/XDC

[David Cole]

Gadi, Binyamin, Rob, Ed, Phil, Hayim and Peter!

Thank you all for good information and a GREAT discussion!

Like some of you, I also am very sensitive to the customer's burden, 
so while creating a "$XDC" class perhaps might be "easy", to 
paraphrase Peter, why would I make a customer do that when I don't have to...


So thank you to those who tipped me off about the XFACILIT. It sounds 
perfect for my needs.


Dave



I've got a problem. Decades ago, I made some assumptions about 
RACF's FACILITY class that have turned out to be wrong.
Currently, I'm working on implementing a new security rule for 
z/XDC, and the individual rules ("entities") can be up to 59 characters long.
Decades ago, when I was porting z/XDC's security rules from ACF2 to 
RACF, I made the decision to piggy-back my security rules into 
RACF's FACILITY class. I didn't know much about RACF then (and I 
still don't), and it did not occur to me that rule length would be 
an issue. I was wrong. It is an issue.
Yesterday, I was testing with an instance of the new rule that was 
44 characters long. Boom! My "RACROUTE REQUEST=AUTH" (racheck) call 
failed with "ICH409I 282-054 ABEND DURING RACHECK PROCESSING". This 
basically means that the entity I passed (my 44-character rule) was 
too long for its class (FACILITY).

Ouch!
So now I have several questions that I'm hoping someone here can 
provide answers to.

What is the longest entity the FACILITY class will accept?
Where do I find that specific fact doc'd?
Is there a command that will display that information?
Is there a catch-all class that z/XDC can use for its rules other 
than FACILITY?

Where do other vendors put their rules?
Asking for a friend [:-J]
Dave Cole


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

Re: unable to access IPCS 64 bit storage using Storage map service

[Joseph Reichman]

I’m using test to debug this thanks 

> On Nov 13, 2023, at 11:28 AM, Adam Johanson 
> <031ca9d720a7-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Joe wrote:
>> I got a number of responses but I decided to use the post By Adam Johanson
>> using storage map services below is my code
> 
>   It appears that I am now pot-committed to this thread, so here goes.
> 
> 
> John P. wrote:
>> My suggestion would be to start from a function use of ADPLSACC which can be 
>> found at https://planetmvs.com/ipcs/ivxSName.txt
> 
>> Once you verify it's functioning correctly, start modifying it to access 64 
>> bit storage. Without a source listing, it's hard to tell if everything is 
>> initialized correctly.
> 
> ADPLSACC doesn't appear to work for accessing 64-bit storage, or at least I 
> couldn't see how to get it to work. This is the reason I went with the 
> Storage Map service and gave it as an example.
> 
> 
> Joe, in your excerpts, these lines pop out:
> 
>> MVC   MAPAST,VIRTUAL#STORAGE Virtual storage address space 
>> MVC   MAPAS2+2(2),ASID#  
> 
> It's not clear what VIRTUAL#STORAGE is, but following the example, MAPAST 
> needs to be set to the ZZZASTCV EQUate for CPU/ASID type. Always better to 
> use the provided EQUates.
> 
> Also, you're moving the ASID# into MAPAS2+2 and it's not clear that the first 
> 2 bytes of MAPAS2 have been initialized to zeroes (I assume that it matters). 
> The code doesn't explicitly initialize them, and the area doesn't appear to 
> be populated by an "initialized" BLSRSASY area. I would suggest having an 
> initialized BLSRSASY area in the constant-area of your program and copy this 
> into your WORKAREA copy. Doing this sets several fields for you that you 
> don't have to explicitly set yourself, chief among them being the ABITS=64 
> business.
> 
> And this line:
> 
>> MVC   MAPFLE,=A(100)
> 
> MAPFLE is 8 bytes.
> 
>   There might be other problems in this sample, but these are the initial 
> ones I see. It might be good to either use a debugger or get a dump at the 
> time of your ADPLSERV invocation and make sure that the areas that you're 
> passing line up with what they're supposed to look like, using the expansions 
> in the listing.
> 
> ===
> Adam Johanson
> Broadcom Mainframe Software Division
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: erroneous BLS18100I message

[Adam Johanson]

John P. wrote:

> VERBX VSMDATA should show allocated 64 storage.

You have to use the RSMDATA subcommand to see the above-the-bar allocations. As 
a starting point, see RSMDATA HIGHVIRTUAL .

===
Adam Johanson
Broadcom Mainframe Software Division

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

Re: unable to access IPCS 64 bit storage using Storage map service

[Adam Johanson]

Joe wrote:
> I got a number of responses but I decided to use the post By Adam Johanson
> using storage map services below is my code 

   It appears that I am now pot-committed to this thread, so here goes.


John P. wrote:
> My suggestion would be to start from a function use of ADPLSACC which can be 
> found at https://planetmvs.com/ipcs/ivxSName.txt

> Once you verify it's functioning correctly, start modifying it to access 64 
> bit storage. Without a source listing, it's hard to tell if everything is 
> initialized correctly.

ADPLSACC doesn't appear to work for accessing 64-bit storage, or at least I 
couldn't see how to get it to work. This is the reason I went with the Storage 
Map service and gave it as an example.


Joe, in your excerpts, these lines pop out:

>  MVC   MAPAST,VIRTUAL#STORAGE Virtual storage address space 
>  MVC   MAPAS2+2(2),ASID#  

It's not clear what VIRTUAL#STORAGE is, but following the example, MAPAST needs 
to be set to the ZZZASTCV EQUate for CPU/ASID type. Always better to use the 
provided EQUates.

Also, you're moving the ASID# into MAPAS2+2 and it's not clear that the first 2 
bytes of MAPAS2 have been initialized to zeroes (I assume that it matters). The 
code doesn't explicitly initialize them, and the area doesn't appear to be 
populated by an "initialized" BLSRSASY area. I would suggest having an 
initialized BLSRSASY area in the constant-area of your program and copy this 
into your WORKAREA copy. Doing this sets several fields for you that you don't 
have to explicitly set yourself, chief among them being the ABITS=64 business.

And this line:

> MVC   MAPFLE,=A(100)

MAPFLE is 8 bytes.

   There might be other problems in this sample, but these are the initial ones 
I see. It might be good to either use a debugger or get a dump at the time of 
your ADPLSERV invocation and make sure that the areas that you're passing line 
up with what they're supposed to look like, using the expansions in the listing.

===
Adam Johanson
Broadcom Mainframe Software Division

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

Re: UNIX "BLKSIZE"?

[Paul Gilmartin]

On Mon, 13 Nov 2023 01:10:14 -0600, Jon Perryman  wrote:
>
>>Suppose I am writing with QSAM/BSAM to a UNIX file allocated
>>RECFM=FB,LRECL=80,FILEDATA=BINARY,PATH=...
>>Should I specify:
>>o BLKSIZE=80 for minimum latency for other jobs doing "tail -f"?
>
>z/OS Unix filesystems are linear datasets. Unless things have changed, BLKSIZE 
>is ignored. LRECL is not stored and must be specified.
> 
No.  BLKSIZE is not ignored.  It is merged into the DCB by OPEN, or supplied
by SDB if not otherwise specified.  for BSAM it affects how many times the
WRITE/CHECK is issued, and probably has some effect on performance
for QSAM.

-- 
gil

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

[Seymour J Metz]

XDAP is basically EXCP with some housekeeping for DASD.



-- 
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי




From: IBM Mainframe Discussion List  on behalf of 
Attila Fogarasi 
Sent: Sunday, November 12, 2023 5:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

Don't forget about XDAP ... that still works, as an alternative to using
access methods :) Of course XDAP is 24-bit only (for the most part).

On Sun, Nov 12, 2023 at 8:11 PM Martin Trübner <
047eec287bd9-dmarc-requ...@listserv.ua.edu> wrote:

> I wrote code that did it and it saved considerable time.
>
>
> Here is the setting/requirments
>
>
> the processing programs can not be changed.
>
> the program skips records till the first correct record is read- then
> does one after the other till out of range or EOF.
>
> The file is FBS (created under VSE which does not support DISP=MOD)
>
> The file needs a full 3390 mod 27 (or bigger)
>
>
> Solution: a POST-OPEN Vendor exit which manipulated the DTFSD such that
> the next (first) read is way into the file.
>
>
> Problem I ran into: multiextent-files (there is no way to tell the
> op-sys to open the n-th extent of a sequential file during above
> mentioned exit). This was no real restrictiooon since the file had its
> own disk anyway - so creating it with singe extent on a disk was easy.
>
>
> Martin
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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


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

Re: RACF, the FACILITY class, and z/XDC

[Hayim Sokolsky]

While some have suggested creating your own class, there is an off-the-shelf 
class suitable for XDC's use: XFACILIT.

- Maximum resource length is 246
- Default return code is 8 (everything is denied if the resource is not defined)

This is just as suitable as creating your own class name, and possible 
preferable if there are going to be a small number of resources.


Just my 2¢..


Hayim

Hayim Sokolsky (he/him/his)
Director, Software Engineering
Rocket Software, USA
E: hsokol...@rocketsoftware.com
W:RocketSoftware.com




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Cole
Sent: Sunday, November 12, 2023 05:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF, the FACILITY class, and z/XDC

EXTERNAL EMAIL





I've got a problem. Decades ago, I made some assumptions about RACF's FACILITY 
class that have turned out to be wrong.

Currently, I'm working on implementing a new security rule for z/XDC, and the 
individual rules ("entities") can be up to 59 characters long.

Decades ago, when I was porting z/XDC's security rules from ACF2 to RACF, I 
made the decision to piggy-back my security rules into RACF's FACILITY class. I 
didn't know much about RACF then (and I still don't), and it did not occur to 
me that rule length would be an issue. I was wrong. It is an issue.

Yesterday, I was testing with an instance of the new rule that was 44 
characters long. Boom! My "RACROUTE REQUEST=AUTH" (racheck) call failed with 
"ICH409I 282-054 ABEND DURING RACHECK PROCESSING". This basically means that 
the entity I passed (my 44-character rule) was too long for its class 
(FACILITY).

Ouch!

So now I have several questions that I'm hoping someone here can provide 
answers to.
* What is the longest entity the FACILITY class will accept?
* Where do I find that specific fact doc'd?
* Is there a command that will display that information?
* Is there a catch-all class that z/XDC can use for its rules other than 
FACILITY?
* Where do other vendors put their rules?

Asking for a friend [:-J]
Dave Cole

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: PC Interference from shredder Was: Kinda fun

[Bob Bridges]

This is why I have some sympathy for the military guys who have to decide what 
knowledge to classify.  We're told all the horror stories about stupidly-held 
secrets that don't need to be secrets, and it isn’t that I don't believe them.  
And the boundaries of one military airfield may not be that big a deal.  But 
sometimes really important secrets can be noodled out from seemingly innocent 
data, and knowing that one can't foresee all the problems must keep those guys 
up at night.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Space isn't remote at all. It's only an hour's drive away, if your car could 
go straight upward.  -Sir Fred Hoyle */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, November 12, 2023 08:56

A co-worker had worked for the FAA at a commercial airport near a military 
airfield.  Military controlled its airspace; airport controlled its.  He made a 
scatter plot of where planes vanished from civilian control, thinking it might 
be useful..He showed it to a military colleague who was aghast that the 
boundary of military control, classified, was publicly available.

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

Re: RACF, the FACILITY class, and z/XDC

[Peter Relson]

Regardless of whether it is hard or easy, why would you
want to bother creating a new class when there is an
existing class (XFACILIT) that completely addresses the problem
(and thus would be easier for a customer)?

Peter Relson
z/OS Core Technology Design


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

Re: RACF, the FACILITY class, and z/XDC

[Rob Scott]

Although setting up your own SAF class is not difficult, it is another step in 
the installation/migration process and my instinct  (bearing in mind the 
squeeze on staffing resources) is always to tend to "zero-config" wherever 
possible.

If you stay within your lanes as far as the profile namespace is concerned 
,then XFACILIT makes sense in most cases.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Sunday, November 12, 2023 8:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF, the FACILITY class, and z/XDC

EXTERNAL EMAIL





Ed Jaffe recommended against creating a SAF class. I'll respectfully suggest 
that it's not that hard.

First, if you do, IBM told us, "Start the class name with a dollar sign-we'll 
never use those". Of course you could collide with another vendor, but that's 
unlikely.

We've had customers doing so for 13 years or so. Besides some folks who didn't 
understand how to use their own ESM, we've had no problems. ACF2 and TSS were 
easy, too.

Now, I admit that our usage is pretty simple: we have named data protection 
entities called Cryptids, and you can use them to protect 
(encrypt/tokenize/hash) or access (decrypt/detokenize) data. So if you have a 
Cryptid named BANANA, a user needs READ or greater authority to PROTECT.BANANA 
or ACCESS.BANANA, as appropriate to use BANANA to protect or access.

For something like EJES, with possibly dozens of subtleties, it would surely be 
harder. The complexity of SAF related to certificates comes to mind, though I 
suspect some of that is due to some historical mistakes. Still, once you've 
defined a scheme, it's just PERMITs, right?


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: erroneous BLS18100I message

[Jon Perryman]

On Sun, 12 Nov 2023 22:35:12 -0500, Joseph Reichman  
wrote:

>I got the following message tracing VERBX routine under TEST
>BLS18100I ASID(X'0040') 01EF_8550 not available
>
>Yet when I do the following running IPCS from the TSO command prompt
> LIST 01EF_8550. ASID(X'0040') LENGTH(X'64') AREA
> _550. 0001  01EF 85501793 |e&.l|

Since I've never used IPCS 64 bit, I don't know what to expect. The BLS18100I 
is missing the "." at the end of the address. In theory, that should not be a 
problem because it starts with a number. The list command output dropped the 
01EF and the 8. Does dropping these mean you are actually in 31 bit mode? Try 
list 550. len(100) to see if it displays the same storage. 

If you have the 64 bit address saved in storage, try using indirect addressing 
using "!".

VERBX VSMDATA should show allocated 64 storage. Maybe try other addresses that 
don't have the 8. I can't remember if the 8 has special meaning in 64 bit mode.

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