IBM Open Enterprise SDK for Node.js 20 is now available!

2023-11-14 Thread Fang Lu
IBM Open Enterprise SDK for Node.js 20 is now available! This latest release 
brings exciting updates and features that Node.js developers on the IBM Z 
platform will appreciate such as the experimental Permission Model, synchronous 
import.meta.resolve, the stable test runner, updates to the V8 JavaScript 
engine to version 11.3, and lots more. 

IBM Open Enterprise SDK for Node.js is available at a no cost license through 
Shopz (5655-NOS) for the SMP/E format, or you can download the pax format at 
https://www.ibm.com/account/reg/us-en/signup?formid=urx-49458. Optional 
world-class IBM Software Subscription and Support is available with your order 
through Shopz (5655-SDS).

For more details about this new release, read the blog: 
https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/chandni-dinani2/2023/11/14/ibm-nodejs-20-is-now-available?CommunityKey=dd64b79b-2641-4911-a0bf-e687936a2a45.
 

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


Re: UNIX "BLKSIZE"?

2023-11-14 Thread Jon Perryman
On Tue, 14 Nov 2023 20:14:37 -0600, Paul Gilmartin  wrote:

>What's XSAM?  Cite an IBM or general IT source.

Tony used the term first and you want to rag on me. It's a lowercase "x" which 
I take as meaning the group of Sequential Access Methods (e.g. QSAM, BSAM, 
VSAM, ...).

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


Re: UNIX "BLKSIZE"?

2023-11-14 Thread Paul Gilmartin
On Tue, 14 Nov 2023 19:04:44 -0600, Jon Perryman wrote:
>
>xSAM works because UNIX files are 1 logical record and it's I/O methods makes 
>each byte of that logical record easily addressable. A single read can read 
>starting at any byte location desired for 1 byte, 1,000 bytes or to the end of 
>that record. It's up to xSAM to determine the most suitable interface to the 
>file.
>
What's XSAM?  Cite an IBM or general IT source.

In z/OS 3.1 documentation I find 4 mentions in Using Data Sets, all directory
names in examples.

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

2023-11-14 Thread Jon Perryman
On Mon, 13 Nov 2023 19:09:26 -0500, Tony Harminc  wrote:

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

ZFS and HFS are filesystems, not files so why would they match UNIX file 
semantics? Files in z/OS filesystems match file semantics within a Unix 
filesystem. 

>> This is conjecture because logic for BSAM communications to the Unix file
>> subsystem is not made publicly. 
>
>I think you're muddling interface levels
>clearly the xSAM interfaces do not talk directly to an underlying VSAM
>filestore, if there is one.

I said UNIX file subsystem. Of course xSAM doesn't use VSAM because all UNIX 
file reads and writes are thru a single address space which manages 
everything.in a single address space. 

>>A Unix file is always 1 logical record. BLKSIZE has no meaning in this 
>>context. 

xSAM works because UNIX files are 1 logical record and it's I/O methods makes 
each byte of that logical record easily addressable. A single read can read 
starting at any byte location desired for 1 byte, 1,000 bytes or to the end of 
that record. It's up to xSAM to determine the most suitable interface to the 
file.

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

2023-11-14 Thread Jack Zukt
Hi,
Rver since IBM gave us CDT, user defined classes migration stopped being a
problem. You no longer need the assembler macros to define user classes.
Everything is in the RACF database.
Best wishes
Jack

On Mon, Nov 13, 2023, 08:42 Rob Scott  wrote:

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

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

2023-11-14 Thread Binyamin Dissen
On Tue, 14 Nov 2023 12:49:54 + Peter Relson  wrote:

:>As was alluded to, if it doesn't work when you "do that" (STIMERM WAIT), then 
don't "do that".

:>If you want to be able to "communicate" then you wait on multiple ECBs and do 
not use STIMERM WAIT, but use STIMERM with an exit that posts one of the ECBs. 
The "communication" can be by posting one of the other ECBs.

:>If you want only to terminate B (disruptively) then use DETACH.

Don't recall ever looking at this, but if STIMER(M) WAIT is instantiated by
SUSPENDing the RB, the parent task can RESUME it. But as that requires
supervisor state, I wonder if it may have side effects when the timer
eventually pops.

--
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: RACF, the FACILITY class, and z/XDC

2023-11-14 Thread Radoslaw Skorupka

Since everyone already answered, here is my answer :-)
1. You can choose your own class.
Advantages:
You choose max. profile length, etc.
Naming conventions is completely up to you, that means no interference 
with other products/profiles, no reserved names/prefixes.

Disadvantage:
Some people are reluctant to create yet another RACF class. And sometime 
they make errors (sample definition should solve it).


2. XFACILIT
Advantages:
Length up to 246 chars
...and something nobody mentioned yet: GXFACILI grouping class. While 
long profiles allow wise naming convention, there is still way to group 
some unlikely named resource names into single profile.

(the same feature can be made in user-defined class as well)

HTH

--
Radoslaw Skorupka
Lodz, Poland





W dniu 12.11.2023 o 11:40, David Cole pisze:
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: ATTACHX/STIMERM WAIT=YES

2023-11-14 Thread Peter Relson
As was alluded to, if it doesn't work when you "do that" (STIMERM WAIT), then 
don't "do that".

If you want to be able to "communicate" then you wait on multiple ECBs and do 
not use STIMERM WAIT, but use STIMERM with an exit that posts one of the ECBs. 
The "communication" can be by posting one of the other ECBs.

If you want only to terminate B (disruptively) then use DETACH.

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

2023-11-14 Thread Ituriel do Neto
David,

Why don't you give the option to select the RACF class to the customer? You can 
give the instructions to create a new class in CDT or instruct them to use the 
XFACILIT class.


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer






Em segunda-feira, 13 de novembro de 2023 às 18:27:18 BRT, David Cole 
 escreveu: 





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

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

2023-11-14 Thread Binyamin Dissen
On Mon, 13 Nov 2023 18:37:15 -0600 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.

Programming.

If you want B to come down nicely you need to provide communication so that A
can tell B to shutdown.

Don't care? Do a DETACH.

--
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: ATTACHX/STIMERM WAIT=YES

2023-11-14 Thread Rob Scott
If the OP would like to see some example source for this sort of thing, I 
included simple task and timer interactions in the "Example Cross-Memory 
Server" code I wrote for Share Dallas.

You can download the code from :

https://github.com/rscott-rocket/mxe

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Tuesday, November 14, 2023 2:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ATTACHX/STIMERM WAIT=YES

EXTERNAL EMAIL





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


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