Re: Any Recovery for RMODE64

[Rob Scott]

Please search the archives.

Peter Relson posted on IBM-Main back in 2020 on the restrictions on RMODE 64 in 
some detail, including recovery issues.

Rob Scott
Rocket Software



Sent from Outlook for Android

From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Thursday, January 25, 2024 11:38:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Any Recovery for RMODE64

EXTERNAL EMAIL





Just wondering is there any recovery for a program running RMODE 64 don't
see that with ESTAE or SETFRR

As more and more services run above the bar

More so SDWAEC1 and SDWAEC2 are only 8 bytes

thanks

--
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: OT-ish: Very old IBM hardware & manuals available

[Leonard D Woren]

I'm pretty sure that the thing I saw was significantly older than 
650.  The bits were so big that they were using an oscilloscope to see 
them.  I don't recall if they said what machine that drum connected 
to.  I had gone there for some big deal event and it was very crowded.


Anyway, it's worth checking with CHM for interest in any old but 
historically significant hardware.


/Leonard

Seymour J Metz wrote on 1/25/2024 5:55 AM:

I started on a 650, and that had a 2,000 word drum. The 305, before my time, 
had a 2400 character drum. I'm not aware of any IBM drum smaller than that.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of Leonard D 
Woren 
Sent: Thursday, January 25, 2024 12:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT-ish: Very old IBM hardware & manuals available

Maybe contact the Computer History Museum https://computerhistory.org/
.  They probably have the resources to ship anything they're
interested in.

Their collection includes IBM hardware that predates any of us having
seen a digital computer.  It's been quite a while since I was there,
but they were working on fixing up an IBM drum storage device which I
think was the size of beer keg and held something like 550 bytes, no
typo, or maybe it was a few kbytes.

/Leonard


Robert Prins wrote on 1/23/2024 7:57 AM:

Hi all,

My father worked for IBM in the Netherlands for more than 30 years,
starting as a CE in the late 1950'ies. Last year he was diagnosed with
Alzheimer, and over the past few months my siblings and me have been
emptying his apartment and storage room, and we've come across a sizeable
quantity of IBM "stuff", from manuals for the 650 to old square cm
"integrated circuits" and even a magnetic core memory card. My siblings
weren't in the least interested in any of it, so I took it, and although
it's nice to look at, our house is already full enough as it is, so...

If anyone thinks they can offer a good home to these things, and I will,
hopefully soon, put pictures of everything that surfaces on my website,
feel free to contact me off this list and we can take it from there. You'll
most definitely be paying for shipping (from Lithuania), and based on what
I'm going to find out on fleabay, I might ask for a bit more.

Robert


--
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: OT-ish: Very old IBM hardware & manuals available

[Tom Gardner]

Robert

Definitely you should contact the Computer History Museum; they are some what 
unique in that they collect old documents and software relating to computers in 
addition, of course, to hardware.  At one point they went to Germany, I think, 
to pick up and ship to the US a whole bunch of old gear.

Go to https://computerhistory.org/acquisitions/ for information on how to make 
a donation

It is best to make the offer online using their form at 
https://airtable.com/appPBw0VORVpnaJbZ/shrgwufDwr5wNVMal 
It really helps them if you can provide as much detail as possible on the 
"stuff," an item by item inventory if possible, and an estimate of the total 
size for shipping purposes.

Their process is the offer will be reviewed by their acquisitions committee and 
if some of your offer fits their missing needs they will accept all or some of 
your offer.
It does take them four weeks or so to get back to you - maybe sooner if really 
interested

Regards,

Tom




-Original Message-
From: Leonard D Woren  
Sent: Wednesday, January 24, 2024 9:38 PM
Subject: Re: OT-ish: Very old IBM hardware & manuals available

Maybe contact the Computer History Museum https://computerhistory.org/ .  They 
probably have the resources to ship anything they're interested in.

Their collection includes IBM hardware that predates any of us having seen a 
digital computer.  It's been quite a while since I was there, but they were 
working on fixing up an IBM drum storage device which I think was the size of 
beer keg and held something like 550 bytes, no typo, or maybe it was a few 
kbytes.

/Leonard


Robert Prins wrote on 1/23/2024 7:57 AM:
> Hi all,
>
> My father worked for IBM in the Netherlands for more than 30 years, 
> starting as a CE in the late 1950'ies. Last year he was diagnosed with 
> Alzheimer, and over the past few months my siblings and me have been 
> emptying his apartment and storage room, and we've come across a 
> sizeable quantity of IBM "stuff", from manuals for the 650 to old 
> square cm "integrated circuits" and even a magnetic core memory card. 
> My siblings weren't in the least interested in any of it, so I took 
> it, and although it's nice to look at, our house is already full enough as it 
> is, so...
>
> If anyone thinks they can offer a good home to these things, and I 
> will, hopefully soon, put pictures of everything that surfaces on my 
> website, feel free to contact me off this list and we can take it from 
> there. You'll most definitely be paying for shipping (from Lithuania), 
> and based on what I'm going to find out on fleabay, I might ask for a bit 
> more.
>
> Robert


--
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 Automation (Cross Posted)

[Bob Bridges]

ACF2 has since added full support for RACF-style groups, and some ACF2 shops 
have made the change to using those instead of UID strings.  This was before 
that, though, and I'm pretty sure they handled it by storing, for each role, 
groups of UID strings.

I don't remember the details of how that worked, but I was their ETL guy and I 
remember creating lots of mass-import data for pouring into SAM-Jupiter.  The 
problem it is was more than twenty years ago, so it's all pretty fuzzy...

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

/* It's extremely difficult to distinguish a Canadian from an American.  In 
fact the most reliable way of doing so is to make that observation in the 
presence of a Canadian.  -attributed at the Gunroom to a "British man of 
letters" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Thursday, January 25, 2024 18:53

It appears that Beta Systems acquired the product and call it Beta-Access. 
https://www.betasystems.com/en/products/beta-access/

It also appears they removed everything except for RACF support.

RACF had groups which made implementing role-based administration easier. ACF2 
and Top-Secret have a different architecture which some customer 
implementations were burdensome to implement within SAM. It also had 
performance implications. However, it had the benefit for customers acquiring 
other companies where they could use the same SAF logic regardless of the SAF 
products being used. It also allowed conversion between SAF products.

--- On Thu, 25 Jan 2024 17:51:46 -0500, Bob Bridges  
wrote:
>Back when my client in Ohio installed it, we called it "Sam-Jupiter". 

> The client seemed content with their choice, although it was really 
> designed to work with RACF and this is an ACF2 client.

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

Re: RACF Automation (Cross Posted)

[Jon Perryman]

On Thu, 25 Jan 2024 17:51:46 -0500, Bob Bridges  wrote:

>Back when my client in Ohio installed it, we called it "Sam-Jupiter". 

It appears that Beta Systems acquired the product and call it Beta-Access. 
https://www.betasystems.com/en/products/beta-access/

It also appears they removed everything except for RACF support.

> The client seemed content with their choice, although it was 
> really designed to work with RACF and this is an ACF2 client.

RACF had groups which made implementing role-based administration easier. ACF2 
and Top-Secret have a different architecture which some customer 
implementations were burdensome to implement within SAM. It also had 
performance implications. However, it had the benefit for customers acquiring 
other companies where they could use the same SAF logic regardless of the SAF 
products being used. It also allowed conversion between SAF products.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Custom ISPF command

[Seymour J Metz]

My editor of choice at home, Tritus SPF, has a BOTTOM command, and I keep 
finding myself typing BOT at work when it should be DOWN MAX. If I do a custom 
command table for ISPF/PDF EDIT,  the first two commands I add will be BOTTOM 
and BOT.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Mark Zelden 
Sent: Thursday, January 25, 2024 2:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Custom ISPF command

On Tue, 23 Jan 2024 16:19:01 -0500, Bob Bridges  wrote:

>I used to add my own commands to the ISPF command table.  But somehow I got 
>out of the habit; I went to a new site, didn't get around to it, got used to 
>just putting "TSO" in front of commands, then forgot where to go to do it the 
>other way.  Now I can find the command table again, but why?  I'm used to the 
>"TSO" prefix, I do it without thinking about it.
>
>This, be it known, is an invitation to tell me "oh, but there are other 
>advantages to the commands table...", which I either never knew or have 
>forgotten.
>


I can think of two off hand (and why I use it from shop to shop / sysplex to 
sysplex)

1) Abbreviations for other ISPF commands in the command table or anything.  For 
example, even
though "DDLIST" is in there from IBM, I add it as an ALIAS of DD.  You can also 
just
copies IBM's entry and change the truncation to 2 chars (or how every many 
suits you).

2) A common / easy name to quickly invoke a product or some other menu option.  
For example,
I have "shortcuts" like HCD, IPCS, SMPE, ISMF, WLM, ISHell, CA1, CA7, SDsd, TMS 
(which I
could point to CA1 or some other tape management product),  IPL (my IPLINFO 
exec) as
some examples.

So for #2, I could have many different clients / shops I am working at and no 
matter which
one I always type "WLM" to get to WLM.  If I'm at a new client / shop, I 
customize this stuff
first once I find it in their own ISPF menus (which sometimes is a challenge!). 
  Then I never
have to find it again and simply type the "shortcut" like WLM from anywhere.   
I also use
it with my "FVE" (fast view/edit) routine to view/edit a parmlib member, VTAMLST
member, my CNTL library, SYS1.IPLPARM, production JCL libraries or anything 
desired
(see my web site for details / samples).

As I wrote, I either put these in USERCMDS if available (depends on local ISPF 
customization),
or merge my commands to SITECMDS (again, if available) or merge into ISPCMDS and
concatenate my table lib before IBM's.I use the dynamic add version like 
the sample
on my web site for systems I rarely access that don't have USERCMDS available
as an option. My sample dynamic commands:   
http://secure-web.cisco.com/1VRXCMKQNkKPv_n7_tIS2DEE6WXqqCYKaiq60VbMphBn-XmX-ySAUqO80uWtk8h42JAJFI4AQDdrvdgHxKF7xa1hs6RAJsxSZy5L_0N_2UsS5_lwkQDdzRXBjhz7Wke1tD50lidy5wjNDwiHOfz_3rpfUi4MBKV4PnHa2oOiMQKOyRPYuMhTJ_7gAaBPBzOQfAbDYNL9cHVS6YXVo_XE8sME0I2yKLfVTejn2M21SvGNpoBPiFnsxlsml6T5R1jwh3xrMFmOhNGH8RwJvZ22MLCXpSHz0cEZEFyqlmKbBB5ACTi8alDwX8nzEaW4C0iKUrWH5sXO13JF1SfOoKXfG5E6Y6_PaVrtFxRl6q4FnVQER7JXuztXODR0VJPEwi7KR78FmWIe1ifzHI1FlbW8ZB1QtrcOoXdGYu5hDVLDYMck/http%3A%2F%2Fwww.mzelden.com%2Fmvsfiles%2Fispcmdsa.txt

I've been working this way for over 30 years and when I get to a new system and 
try
to work without it, I am not nearly as productive.   But more than that, for 
someone
like me that is working on many different sysplexes, clients, etc. all in a 
short time
period of time or constantly switching between them, having a consistent way to 
get
to all the ISPF interfaces / products keeps me from making mistakes.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: 
http://secure-web.cisco.com/1wvncvod9NtUsJ1i2o2cWgwIbRR9rrJqIfuThjfgtQwoN3kDbty1-ioXUgC7Kf6wkbKmp00JmrJIA-FoEEmDuIsLN-2lrhDu4sU1GcB2kI7Rx2jWDZilDrWGb4auGHjDYrbqA4pvJDt7hxkkar9pxqAn-WryAVU2HXqv5VzG2jOVNFsGQ7xZoDfmjsHXiLgrcDzxIAaQKZa5EmoDPiZatmqekr0Ze7dCxCi42rg1AM9crPlaBKG36-rn0dOmVozpTLJrq54xOEwwp6TnV2GO3AnjJkNsbahYtk8cDlfmVTRTj5JVsugXV8CXXiSES-Et2ljSnT53JAna2Aaj856cjbQTVB2J39vJisdgf-ZeHoQshoy5dYO2uewFrG4W_SmoHMQKjQXmhLr4aO5wG-sicawZ0QIJwJiJXdNExgr7QmzA/http%3A%2F%2Fwww.mzelden.com%2Fmvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
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

Any Recovery for RMODE64

[Joseph Reichman]

Just wondering is there any recovery for a program running RMODE 64 don't
see that with ESTAE or SETFRR

As more and more services run above the bar 

More so SDWAEC1 and SDWAEC2 are only 8 bytes

thanks 

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

Re: Custom ISPF command

[Bob Bridges]

Good point.  I do the same kind of thing already with dataset names; I keep a 
table at each client for my own libraries, and no matter where I go my general 
REXX library is XG, my JCL library is JG, a scratch data library is DG and so 
on.  There are other abbreviations; XT is the "team" exec library where I put 
routines that should be available to everyone on my team.  No need to think 
about what I had to name it here; the RENDSN function looks up the alias and 
returns the correct DSN.

Of course I also put shortcuts in there for long-winded names of production 
libraries that I have to refer to frequently enough.

Anyway, yeah, makes sense to do that for command names too.

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

/* No one would talk much in society if he knew how often he misunderstands 
others.  -Goethe */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Zelden
Sent: Thursday, January 25, 2024 14:50

2) A common / easy name to quickly invoke a product or some other menu option.  
For example, I have "shortcuts" like HCD, IPCS, SMPE, ISMF, WLM, ISHell, CA1, 
CA7, SDsd, TMS (which I could point to CA1 or some other tape management 
product),  IPL (my IPLINFO exec) as some examples. 

So for #2, I could have many different clients / shops I am working at and no 
matter which one I always type "WLM" to get to WLM

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

Re: RACF Automation (Cross Posted)

[Bob Bridges]

Back when my client in Ohio installed it, we called it "Sam-Jupiter".  I don't 
know what the extra name implies.  The client seemed content with their choice, 
although it was really designed to work with RACF and this is an ACF2 client.

Also Sailpoint, but I think you mentioned that possibility already.

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

/* Getting an inch of snow is like winning 10 cents in the lottery.  -from 
_Calvin & Hobbes_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Thursday, January 25, 2024 14:08

See if SAM (Security Administration Manager) still exists (possibly rebranded). 
The company no longer exists but I found 
https://dl.acm.org/doi/pdf/10.1145/266741.266758 which described the product. 

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

Re: Encryption and decryption - processor or TCPIP

[Radoslaw Skorupka]

To complement, clarify and organize in few points:

1. We have symmetric and asymmetric crypto. And some other 
crypto-related functions (SHA, RNG). However it worth to know, the 
asymmetric crypto is approx. 1000 times slower than symmetric crypto 
(with the same crypto-strength). That's why we use asymmetric crypto 
only when symmetric cannot be used. The example is SSL/TLS - we start 
with asymmetric just for handshake process and quickly switch to symmetric.


2. They key is ...key. I mean private key and symmetric key should be 
kept in secret. That's why we have *secure key* and clear key 
cryptography. The last one means authorized (and educated) user can find 
it in memory. Secure key cannot be found, because it reside in clear 
form only in HSM - special tamper-protected crypto hardware. Read: 
CryptoExpress card. Note, there is also something between - protected 
key cryptography. In this case user cannot read the key, but this 
flavour is has no high FIPS certification.


3. You may want to use CryptoExpress for two reasons: asymmetric crypto 
offload (performance) and for symmetric crypto operations with secure 
key (security, compliance).


4. Note, large number of small-block symmetric operations on 
CryptoExpress mean much worse performance than CPACF, due to I/O. 
CryptoExpress is peripheral device.
However the larger block and the stronger algorithm, the better 
performance from CryptoExpress.


5. CPACF does not offer any asymmetric operations, so there is no 
comparison to CryptoExpress. Instead it can be pure software 
implementation, which means even worse. It is worth to note: CPACF, 
CryptoExpress and just software (as any other application code). CPACF 
is the fastest, but CryptoExpress offers more functions. So it is better 
to use CPACF whenever possible (compliance, etc.), then CryptoExpress 
then software. Note, the software can be offloaded to zIIP.


6. CPACF functions can be called as ICSF services, but some of them can 
be invoked directly from assembler code.


7. CryptoExpress is paid feature, it is a card, like FICON or OSA. CPACF 
is "for free" (read included in the price). However due to export 
limitations it is enabled (FC 3863) or not. Usually yes. And the 3863 is 
prereq for CryptoExpress.


8. AFAIK few CPACF crypto services (SHA?) are available even without FC 
3863.



My €0.02

--
Radoslaw Skorupka
Lodz, Poland



W dniu 25.01.2024 o 22:28, Charles Mills pisze:

I'm trying to put this in my own words. I'm not an expert on Z crypto 
architecture, but I am sure someone will correct me if I am wrong.

The CPACF instructions are like the TRT instruction. You *could* do what TRT 
does with a loop using IC and compare and so forth, but the TRT instruction is 
much faster. It's a relatively slow instruction as instructions go, while still 
much faster than a loop. But it's a machine instruction. The CPU is busy and 
running up CPU time for the task the whole time that TRT takes. The same for 
CPACF instructions: faster than a loop, but still machine instructions that 
consume CPU time.

The crypto cards are a little like a DASD drive. The control program can say "go do this" 
and then suspend the task in question and go do other things or go into a wait state. The task 
accrues no CPU time while the crypto card is doing its thing, much the way it accrues no CPU time 
while the DASD does its thing. Like DASD, when the crypto card completes its operation, it comes 
back to the control program and says "I'm done, here is your result." The task resumes 
executing, presumably using the results of the crypto operation. The function is overall faster 
than a loop, and way more economical in terms of CPU time.

A little encryption background:

Symmetric or "secret key" encryption is probably what you think of when you 
think of encryption. You encrypt and decrypt with the same secret key, just like when you 
passed coded notes in grade school. It is a part of almost everything where encryption is 
involved. It is slow as things go, but it is relatively fast compared to

Asymmetric or "public key" encryption. The big problem with symmetric encryption is "how do you deliver 
that secret key to the other end of the line?" For DASD encryption, that is not an issue, because both "ends 
of the line" are right there on your machine. But for communication situations, where the other end is far away 
and there is no secure path (until you have the encryption set up) and thus no way to deliver that secret key to the 
other end, other than a guy on a plane with a briefcase padlocked to his wrist. Asymmetric encryption is like magic! 
You use one key for encryption and a different key for decryption. (The two keys have a complex mathematical 
relationship to each other, and even computing that relationship takes a lot of time.) So you can encode something with 
the other end's completely public public key, and only that other end, that has the corresponding private key, can 
decrypt it! 

Re: Encryption and decryption - processor or TCPIP

[Rick Troth]

Nicely put.

> Symmetric or "secret key" encryption is probably what you think of 
when you think of encryption.
> You encrypt and decrypt with the same secret key, just like when you 
passed coded notes in grade school.
> It is a part of almost everything where encryption is involved. It is 
slow as things go, but it is relatively fast compared to ...


You nailed the description, but I recommend *not* calling it "secret 
key" encryption because in asymmetric there is a /secret/ key. (Call it 
the /private/ key. But some still call it the secret key.)
A better term might be "/single/ key encryption" because there is only 
one key. It's like a house key: it both locks and unlocks. (Or like 
coded notes in grade school, yep.)
Symmetric is more accurate, but not a term lay people use. (But we could 
... uhh ... school them.) *:-)*


Also ... spot on about key distribution problems.
Some of us in VM land have started tinkering with a trust anchor.

Absolutely right about that "random secret key".
Better term there is /session/ key. All our current crypto combines 
asymmetric (for trust) with symmetric (for speed): TLS/SSL (call it 
PKI), SSH, PGP/GPG.


-- R; <><


On 1/25/24 16:28, Charles Mills wrote:

I'm trying to put this in my own words. I'm not an expert on Z crypto 
architecture, but I am sure someone will correct me if I am wrong.

The CPACF instructions are like the TRT instruction. You *could* do what TRT 
does with a loop using IC and compare and so forth, but the TRT instruction is 
much faster. It's a relatively slow instruction as instructions go, while still 
much faster than a loop. But it's a machine instruction. The CPU is busy and 
running up CPU time for the task the whole time that TRT takes. The same for 
CPACF instructions: faster than a loop, but still machine instructions that 
consume CPU time.

The crypto cards are a little like a DASD drive. The control program can say "go do this" 
and then suspend the task in question and go do other things or go into a wait state. The task 
accrues no CPU time while the crypto card is doing its thing, much the way it accrues no CPU time 
while the DASD does its thing. Like DASD, when the crypto card completes its operation, it comes 
back to the control program and says "I'm done, here is your result." The task resumes 
executing, presumably using the results of the crypto operation. The function is overall faster 
than a loop, and way more economical in terms of CPU time.

A little encryption background:

Symmetric or "secret key" encryption is probably what you think of when you 
think of encryption. You encrypt and decrypt with the same secret key, just like when you 
passed coded notes in grade school. It is a part of almost everything where encryption is 
involved. It is slow as things go, but it is relatively fast compared to

Asymmetric or "public key" encryption. The big problem with symmetric encryption is "how do you deliver 
that secret key to the other end of the line?" For DASD encryption, that is not an issue, because both "ends 
of the line" are right there on your machine. But for communication situations, where the other end is far away 
and there is no secure path (until you have the encryption set up) and thus no way to deliver that secret key to the 
other end, other than a guy on a plane with a briefcase padlocked to his wrist. Asymmetric encryption is like magic! 
You use one key for encryption and a different key for decryption. (The two keys have a complex mathematical 
relationship to each other, and even computing that relationship takes a lot of time.) So you can encode something with 
the other end's completely public public key, and only that other end, that has the corresponding private key, can 
decrypt it! Magic! Problem solved. Except that asymmetric encryption is really, really, really slow. Specialized 
hardware makes it faster, but it is still really, really slow. So how is it usable then in the real world? The answer 
is that you never encrypt "real data" with asymmetric encryption. You make up a random secret key, deliver it 
to the other end using public key (rather than a guy with a briefcase) and then use that random secret key for 
symmetric encryption of the real data.

So symmetric encryption is used for everything, and asymmetric encryption is 
used in addition for things where the other end is remote. (That combo is often 
something called SSL or TLS, and they also make extensive use of our other old 
friends, digital certificates.)

CM

On Thu, 25 Jan 2024 13:01:17 -0600, Alan Altmark  
wrote:


On Wed, 24 Jan 2024 20:15:18 +0400, Peter  wrote:

Still I am trying to understand encryption and decryption load goes to
general CP In case if you don't have CPACF or ICSF ?

There's no such thing as "don't have CPACF".   All machines have it.  It's 
on-chip and part of the instruction set.

The only variable is whether or not the no-charge hardware cryptographic 
feature 3863 is enabled (in countries 

Re: Encryption and decryption - processor or TCPIP

[Charles Mills]

I'm trying to put this in my own words. I'm not an expert on Z crypto 
architecture, but I am sure someone will correct me if I am wrong.

The CPACF instructions are like the TRT instruction. You *could* do what TRT 
does with a loop using IC and compare and so forth, but the TRT instruction is 
much faster. It's a relatively slow instruction as instructions go, while still 
much faster than a loop. But it's a machine instruction. The CPU is busy and 
running up CPU time for the task the whole time that TRT takes. The same for 
CPACF instructions: faster than a loop, but still machine instructions that 
consume CPU time.

The crypto cards are a little like a DASD drive. The control program can say 
"go do this" and then suspend the task in question and go do other things or go 
into a wait state. The task accrues no CPU time while the crypto card is doing 
its thing, much the way it accrues no CPU time while the DASD does its thing. 
Like DASD, when the crypto card completes its operation, it comes back to the 
control program and says "I'm done, here is your result." The task resumes 
executing, presumably using the results of the crypto operation. The function 
is overall faster than a loop, and way more economical in terms of CPU time.

A little encryption background:

Symmetric or "secret key" encryption is probably what you think of when you 
think of encryption. You encrypt and decrypt with the same secret key, just 
like when you passed coded notes in grade school. It is a part of almost 
everything where encryption is involved. It is slow as things go, but it is 
relatively fast compared to

Asymmetric or "public key" encryption. The big problem with symmetric 
encryption is "how do you deliver that secret key to the other end of the 
line?" For DASD encryption, that is not an issue, because both "ends of the 
line" are right there on your machine. But for communication situations, where 
the other end is far away and there is no secure path (until you have the 
encryption set up) and thus no way to deliver that secret key to the other end, 
other than a guy on a plane with a briefcase padlocked to his wrist. Asymmetric 
encryption is like magic! You use one key for encryption and a different key 
for decryption. (The two keys have a complex mathematical relationship to each 
other, and even computing that relationship takes a lot of time.) So you can 
encode something with the other end's completely public public key, and only 
that other end, that has the corresponding private key, can decrypt it! Magic! 
Problem solved. Except that asymmetric encryption is really, really, really 
slow. Specialized hardware makes it faster, but it is still really, really 
slow. So how is it usable then in the real world? The answer is that you never 
encrypt "real data" with asymmetric encryption. You make up a random secret 
key, deliver it to the other end using public key (rather than a guy with a 
briefcase) and then use that random secret key for symmetric encryption of the 
real data. 

So symmetric encryption is used for everything, and asymmetric encryption is 
used in addition for things where the other end is remote. (That combo is often 
something called SSL or TLS, and they also make extensive use of our other old 
friends, digital certificates.)

CM

On Thu, 25 Jan 2024 13:01:17 -0600, Alan Altmark  
wrote:

>On Wed, 24 Jan 2024 20:15:18 +0400, Peter  wrote:
>>Still I am trying to understand encryption and decryption load goes to
>>general CP In case if you don't have CPACF or ICSF ?
>
>There's no such thing as "don't have CPACF".   All machines have it.  It's 
>on-chip and part of the instruction set. 
>
>The only variable is whether or not the no-charge hardware cryptographic 
>feature 3863 is enabled (in countries where it is offered).  It controls the 
>amount of function in CPACF and whether or not you can use the crypto cards.  
>Let's assume you have the feature enabled.
>
>As Eric has replied, CPACF is focused on symmetric (shared key) cryptographic 
>operations.  That's because symmetric operations can be done quickly, and far 
>more efficiently than doing it in software. But CPACF is not an offload 
>operation.  All of the cycles are on the processor.

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

Re: Unknopwn device type 3030200F

[Matthew Stitt]

That's a 3390.  See the CBTTAPE, file 527, member DATASECT (part of LISTICAT)

Matthew Stitt

On Thu, 25 Jan 2024 11:00:38 +0100, MANCINI Frédéric (80) 
 wrote:

>Hello,
>We are trying to recover a catalog's contents by using the output of a
>previous LISTCAT.
>The device type 3030200F does not seem to be documented
>(https://www.ibm.com/docs/en/zos/2.3.0?topic=fields-device-type-translate-table).
>Does anyone know the corresponding device ?
>Regards,
>Frédéric Mancini
>

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

Re: Custom ISPF command

[Mark Zelden]

On Tue, 23 Jan 2024 16:19:01 -0500, Bob Bridges  wrote:

>I used to add my own commands to the ISPF command table.  But somehow I got 
>out of the habit; I went to a new site, didn't get around to it, got used to 
>just putting "TSO" in front of commands, then forgot where to go to do it the 
>other way.  Now I can find the command table again, but why?  I'm used to the 
>"TSO" prefix, I do it without thinking about it.
>
>This, be it known, is an invitation to tell me "oh, but there are other 
>advantages to the commands table...", which I either never knew or have 
>forgotten.
>


I can think of two off hand (and why I use it from shop to shop / sysplex to 
sysplex)

1) Abbreviations for other ISPF commands in the command table or anything.  For 
example, even
though "DDLIST" is in there from IBM, I add it as an ALIAS of DD.  You can also 
just
copies IBM's entry and change the truncation to 2 chars (or how every many 
suits you).

2) A common / easy name to quickly invoke a product or some other menu option.  
For example,
I have "shortcuts" like HCD, IPCS, SMPE, ISMF, WLM, ISHell, CA1, CA7, SDsd, TMS 
(which I 
could point to CA1 or some other tape management product),  IPL (my IPLINFO 
exec) as
some examples. 

So for #2, I could have many different clients / shops I am working at and no 
matter which
one I always type "WLM" to get to WLM.  If I'm at a new client / shop, I 
customize this stuff
first once I find it in their own ISPF menus (which sometimes is a challenge!). 
  Then I never
have to find it again and simply type the "shortcut" like WLM from anywhere.   
I also use
it with my "FVE" (fast view/edit) routine to view/edit a parmlib member, VTAMLST
member, my CNTL library, SYS1.IPLPARM, production JCL libraries or anything 
desired
(see my web site for details / samples).  

As I wrote, I either put these in USERCMDS if available (depends on local ISPF 
customization),
or merge my commands to SITECMDS (again, if available) or merge into ISPCMDS and
concatenate my table lib before IBM's.I use the dynamic add version like 
the sample
on my web site for systems I rarely access that don't have USERCMDS available
as an option. My sample dynamic commands:   
http://www.mzelden.com/mvsfiles/ispcmdsa.txt

I've been working this way for over 30 years and when I get to a new system and 
try
to work without it, I am not nearly as productive.   But more than that, for 
someone
like me that is working on many different sysplexes, clients, etc. all in a 
short time
period of time or constantly switching between them, having a consistent way to 
get
to all the ISPF interfaces / products keeps me from making mistakes.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Automation (Cross Posted)

[Jon Perryman]

On Thu, 25 Jan 2024 10:15:57 -0600, Steve Beaver  wrote:

>I don't even know if the product still exists. -- The closest IVP that I know 
>of is OKTA.

See if SAM (Security Administration Manager) still exists (possibly rebranded). 
The company no longer exists but I found 
https://dl.acm.org/doi/pdf/10.1145/266741.266758 which described the product. 

>The down side of ROLLING your own you have to administer and maintain it
>And no one wants to spend the couple hundred thousand to write and watch 
>people retire.

You haven't defined the customer's expectation of "Automate RACF". To say 
"couple hundred thousand $" is meaningless because at this point you don't know 
the customers problem.. Maybe the customer simply needs standards that simplify 
and consolidate the process. Products like AutoOperator may simplify 
distribution of security definitions to a few simple execs.

What is the problem that the customer trying to solve? Maybe the customer will 
find an 80% solution written in 2 weeks is acceptable. 

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

Re: Encryption and decryption - processor or TCPIP

[Alan Altmark]

On Wed, 24 Jan 2024 20:15:18 +0400, Peter  wrote:
>Still I am trying to understand encryption and decryption load goes to
>general CP In case if you don't have CPACF or ICSF ?

There's no such thing as "don't have CPACF".   All machines have it.  It's 
on-chip and part of the instruction set. 

The only variable is whether or not the no-charge hardware cryptographic 
feature 3863 is enabled (in countries where it is offered).  It controls the 
amount of function in CPACF and whether or not you can use the crypto cards.  
Let's assume you have the feature enabled.

As Eric has replied, CPACF is focused on symmetric (shared key) cryptographic 
operations.  That's because symmetric operations can be done quickly, and far 
more efficiently than doing it in software. But CPACF is not an offload 
operation.  All of the cycles are on the processor.

For asymmetric cryptography, CPACF offers some help, but the real acceleration 
comes with the crypto cards.  It's very visible when you start up a subsystem 
that clients are trying to connect to.  E.g. telnet server, CICS, db2.  
Hundreds or thousands of clients may all be trying to connect at the same time. 
 Those TLS handshakes are significantly accelerated by offloading the 
asymmetric cryptography to the crypto cards where it runs in parallel to 
whatever is happening on the CP.

Alan Altmark
IBM

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

Re: pax and extended attributes

[Radoslaw Skorupka]

W dniu 25.01.2024 o 18:07, Paul Gilmartin pisze:

On Thu, 25 Jan 2024 14:42:46 +0100, Radoslaw Skorupka wrote:


I have to move some directory trees from one file system location to
another.
The tree is rather complex (dozen directories, hundreds files) and some
files do have extended attributes.
My goal is to preserve all the metadata like files ownership, FSP, ACL,
tags, audit flags, etc.

I tried to use pax


Wouldn't it be nice if z/OS supported virtual disks, akin to .iso or .dmg?
(Idea?)


Yes, it would be nice. As many other features which I don't need now.


*But* some of the information you need to preserve probably resides
outside the filesystem, such as ACL, tags, audit flags, etc., even as
a snapshot copy of a CKD DASD might not preserve catalog and
RACF information.


I don't think so. All of the metadata are moved with ZFS dataset and 
exist even if you mount it in another z/OS system.


Regarding .iso images - it would be good to upload a CD. Or download 
some USS tree.
However in my case the goal is to move some tree to another location, 
despite of physical ZFS boundaries. Whole ZFS can be easily copied using 
IDCAMS or ADRDSSU, etc.




BTW, for record purposes: -p e and -x pax do the job.
-x pax is relatively new archive format and include -o saveext. This is 
for -w archive

-p e reads all the attributes, acl's, etc. This is for -r archive
It is also possible to use copy mode
pax -rw -p e source dest

Thanks for the hint!

--
Radoslaw Skorupka
Lodz, Poland

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

Re: pax and extended attributes

[Paul Gilmartin]

On Thu, 25 Jan 2024 14:42:46 +0100, Radoslaw Skorupka wrote:

>I have to move some directory trees from one file system location to
>another.
>The tree is rather complex (dozen directories, hundreds files) and some
>files do have extended attributes.
>My goal is to preserve all the metadata like files ownership, FSP, ACL,
>tags, audit flags, etc.
>
>I tried to use pax
>
Wouldn't it be nice if z/OS supported virtual disks, akin to .iso or .dmg?
(Idea?)

*But* some of the information you need to preserve probably resides
outside the filesystem, such as ACL, tags, audit flags, etc., even as
a snapshot copy of a CKD DASD might not preserve catalog and
RACF information.

-- 
gil

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

Re: New SSH vulnerability

[Kirk Wolf]

1)  /etc/ssh/zos_ssh_config
CiphersSource ICSF
This has nothing to do with the CVE, and I wouldn't use this.   The default 
(CPACF) uses significantly less CPU than going through ICSF.   Same goes for 
MACsSource

2. /etc/ssh/sshd_config
Algorithms to exclude:

Ciphers   #remove the following:
chacha20-poly1...@openssh.com

Macs  # remove the following:
hmac-sha2-512-...@openssh.com
hmac-sha2-256-...@openssh.com
hmac-sha1-...@openssh.com 
hmac-md5-...@openssh.com

3. You should do the same Cipher and MACs changes in /etc/ssh/ssh_config, 
otherwise you are only protecting SSHD connections from this MITM attack.

FYI - information on configuring OpenSSH can be found here:

https://coztoolkit.com/docs/pt-quick-inst/pto-inst-cpacf.html#pto-inst-cpacf-enable


Kirk Wolf
Dovetailed Technologies
http:// coztoolkit.com

On Thu, Jan 25, 2024, at 10:26 AM, Jousma, David wrote:
> We were able to remediate the situation by the following ssh config changes.  
>Thanks to our invisible friend kekronbekron for pointing me to some 
> additional helpful information.
> 
> 
> EDIT /etc/ssh/zos_ssh_config
> 
> Command ===>
> 
> ** *
> 
> 01 # set crypto options
> 
> 02 CiphersSource ICSF
> 
> 
> 
> 
> 
> EDIT /etc/ssh/sshd_config
> 
> Command ===>
> 
> 000102 Subsystem sftp /usr/lib/ssh/sftp-server
> 
> 000103
> 
> 000104 #set crypto options
> 
> 000105 Ciphers 
> aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com
> 
> 
> Dave Jousma
> Vice President | Director, Technology Engineering
> 
> 
> 
> 
> 
> From: Jousma, David 
> Date: Thursday, January 25, 2024 at 9:04 AM
> To: IBM-Main (ibm-main@listserv.ua.edu) 
> Subject: New SSH vulnerability
> Looks like a fairly new SSH vulnerability has surfaced…Anyone figure out a 
> local remediation for this yet?   As per usual, IBM is mum.   There is no 
> fixing PTF yet based on what I see in ResourceLink.
> 
> 
> QID
> 
> 38913
> 
> Severity
> 
> HIGH
> 
> Definition
> 
> SSH Prefix Truncation Vulnerability (Terrapin)
> 
> Description
> 
> The Terrapin attack exploits weaknesses in the SSH transport layer protocol 
> in combination with newer cryptographic algorithms and encryption modes 
> introduced by OpenSSH over 10 years ago. Since then, these have been adopted 
> by a wide range of SSH implementations, therefore affecting a majority of 
> current implementations.
> 
> 
> 
> 
> 
> QID Detection Logic (Unauthenticated):
> 
> 
> 
> This detection attempts to start the SSH key exchange process and examines 
> whether either of the vulnerable ChaCha20-Poly1305 Algorithm or CBC-EtM 
> Algorithm is active. It subsequently verifies whether Strict Key Exchange is 
> enabled. If a target is identified as vulnerable, it indicates that the 
> target supports either of the vulnerable algorithms and lacks support for 
> Strict Key Exchange.
> 
> Solution
> 
> Customers are advised to refer to the individual vendor advisory for their 
> operating system and install the patch released by the vendor. For more 
> information regarding the vulnerability, please refer to Terrapin 
> Vulnerability
> 
> 
> 
> Patch:
> 
> 
> 
> Following are links for downloading patches to fix the vulnerabilities:
> 
> OpenWall Security Advisory
> 
> Impact
> 
> Successful exploitation of the vulnerability may allow an attacker to 
> downgrade the security of an SSH connection when using SSH extension 
> negotiation. The impact in practice heavily depends on the supported 
> extensions. Most commonly, this will impact the security of client 
> authentication when using an RSA public key.
> 
> CVEs
> 
> CVE-2023-48795
> 
> Results
> 
> SSH Prefix Truncation Vulnerability (Terrapin) detected on port: 22
> 
> ChaCha20-Poly1305 Algorithm Support: True
> 
> CBC-EtM Algorithm Support: False
> 
> Strict Key Exchange algorithm enabled: False
> 
> EVM Report
> 
> Yes
> 
> EVM Risk Score
> 
> 4.9
> 
> Host Details
> 
> Host
> 
> 192.168.30.2
> 
> IP Address
> 
> 192.168.30.2
> 
> Operating System
> 
> IBM OS/390
> 
> Tier
> 
> T3
> 
> FQDN
> 
> 
> 
> Port
> 
> 22
> 
> Protocol
> 
> tcp
> 
> 
> 
> 
> Dave Jousma
> Vice President | Director, Technology Engineering
> 
> 
> 
> 
> 
> 
> This e-mail transmission contains information that is confidential and may be 
> privileged.   It is intended only for the addressee(s) named above. If you 
> receive this e-mail in error, please do not read, copy or disseminate it in 
> any manner. If you are not the intended recipient, any disclosure, copying, 
> distribution or use of the contents of this information is prohibited. Please 
> reply to the message immediately by informing the sender that the message was 
> misdirected. After replying, please erase it from your computer system. Your 
> assistance in correcting this error is appreciated.
> 
> 
> 

Re: New SSH vulnerability

[Jousma, David]

We were able to remediate the situation by the following ssh config changes.
 Thanks to our invisible friend kekronbekron for pointing me to some additional 
helpful information.


EDIT /etc/ssh/zos_ssh_config

Command ===>

** *

01 # set crypto options

02 CiphersSource ICSF





EDIT /etc/ssh/sshd_config

Command ===>

000102 Subsystem sftp /usr/lib/ssh/sftp-server

000103

000104 #set crypto options

000105 Ciphers 
aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com


Dave Jousma
Vice President | Director, Technology Engineering





From: Jousma, David 
Date: Thursday, January 25, 2024 at 9:04 AM
To: IBM-Main (ibm-main@listserv.ua.edu) 
Subject: New SSH vulnerability
Looks like a fairly new SSH vulnerability has surfaced…Anyone figure out a 
local remediation for this yet?   As per usual, IBM is mum.   There is no 
fixing PTF yet based on what I see in ResourceLink.


QID

38913

Severity

HIGH

Definition

SSH Prefix Truncation Vulnerability (Terrapin)

Description

The Terrapin attack exploits weaknesses in the SSH transport layer protocol in 
combination with newer cryptographic algorithms and encryption modes introduced 
by OpenSSH over 10 years ago. Since then, these have been adopted by a wide 
range of SSH implementations, therefore affecting a majority of current 
implementations.





QID Detection Logic (Unauthenticated):



This detection attempts to start the SSH key exchange process and examines 
whether either of the vulnerable ChaCha20-Poly1305 Algorithm or CBC-EtM 
Algorithm is active. It subsequently verifies whether Strict Key Exchange is 
enabled. If a target is identified as vulnerable, it indicates that the target 
supports either of the vulnerable algorithms and lacks support for Strict Key 
Exchange.

Solution

Customers are advised to refer to the individual vendor advisory for their 
operating system and install the patch released by the vendor. For more 
information regarding the vulnerability, please refer to Terrapin Vulnerability



Patch:



Following are links for downloading patches to fix the vulnerabilities:

OpenWall Security Advisory

Impact

Successful exploitation of the vulnerability may allow an attacker to downgrade 
the security of an SSH connection when using SSH extension negotiation. The 
impact in practice heavily depends on the supported extensions. Most commonly, 
this will impact the security of client authentication when using an RSA public 
key.

CVEs

CVE-2023-48795

Results

SSH Prefix Truncation Vulnerability (Terrapin) detected on port: 22

ChaCha20-Poly1305 Algorithm Support: True

CBC-EtM Algorithm Support: False

Strict Key Exchange algorithm enabled: False

EVM Report

Yes

EVM Risk Score

4.9

Host Details

Host

192.168.30.2

IP Address

192.168.30.2

Operating System

IBM OS/390

Tier

T3

FQDN



Port

22

Protocol

tcp




Dave Jousma
Vice President | Director, Technology Engineering






This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: RACF Automation (Cross Posted)

[Steve Beaver]

I don't even know if the product still exists. -- The closest IVP that I know 
of is OKTA.  OTKA 
Can administer lockouts and password.  However in our world there is nothing 
cheap
And easy.  The down side of ROLLING your own you have to administer and 
maintain it
And no one wants to spend the couple hundred thousand to write and watch people 
retire.


Steve 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jon Perryman
Sent: Thursday, January 25, 2024 10:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF Automation (Cross Posted)

On Tue, 23 Jan 2024 12:39:47 -0600, Steve Beaver  wrote:

>I have a customer that would like to AUTOMATE RACF. 

Did you solve your problem?

You need to clarify what AUTOMATE RACF means to the customer. What is the 
problem the customer is trying to solve because they can't mean automate. 
Security definitions requires someone to fill in the blanks. Are they looking 
to simplify the process and streamline it with a company's security strategy.

I worked on a product that centralized security thru a single interface (RACF, 
TopSecret, ACF2, Unix, Windows and others. It's been many years and I don't 
even know if the product still exists.

If you can describe the problem, then we might have some suggestions to solve 
your problem.

--
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 Automation (Cross Posted)

[Jon Perryman]

On Tue, 23 Jan 2024 12:39:47 -0600, Steve Beaver  wrote:

>I have a customer that would like to AUTOMATE RACF. 

Did you solve your problem?

You need to clarify what AUTOMATE RACF means to the customer. What is the 
problem the customer is trying to solve because they can't mean automate. 
Security definitions requires someone to fill in the blanks. Are they looking 
to simplify the process and streamline it with a company's security strategy.

I worked on a product that centralized security thru a single interface (RACF, 
TopSecret, ACF2, Unix, Windows and others. It's been many years and I don't 
even know if the product still exists.

If you can describe the problem, then we might have some suggestions to solve 
your problem.

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

Re: New SSH vulnerability

[Rick Troth]

Allan speaks truth.

Looks like the OpenSSH team addressed the Terrapin attack hot on the 
heels of the CVE ...


https://www.openssh.com/releasenotes.html

(9.6 is discussed at the top of the release notes)

OpenSSH 9.6p1 is in the Chicory collection.
(Was troublesome because of forced upgrades presumably not related to 
CVE-2023-48795, but did eventually build.)
I've got it built for Linux and FreeBSD with more to come. There's a 
z/OS build here ...


https://github.com/ZOSOpenTools/opensshport/releases/download/STABLE_opensshport_1953/openssh-9.6p1.20240109_105141.zos.pax.Z

For more info about the vulnerability, see here ...

https://nvd.nist.gov/vuln/detail/CVE-2023-48795

-- R; <><


On 1/25/24 09:20, Allan Staller wrote:

Classification: Confidential

It does take some time for the fixes to be developed, tested and distributed.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Thursday, January 25, 2024 8:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: New SSH vulnerability

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Looks like a fairly new SSH vulnerability has surfaced...Anyone figure out a 
local remediation for this yet?   As per usual, IBM is mum.   There is no 
fixing PTF yet based on what I see in ResourceLink.


QID

38913

Severity

HIGH

Definition

SSH Prefix Truncation Vulnerability (Terrapin)

Description

The Terrapin attack exploits weaknesses in the SSH transport layer protocol in 
combination with newer cryptographic algorithms and encryption modes introduced 
by OpenSSH over 10 years ago. Since then, these have been adopted by a wide 
range of SSH implementations, therefore affecting a majority of current 
implementations.





QID Detection Logic (Unauthenticated):



This detection attempts to start the SSH key exchange process and examines 
whether either of the vulnerable ChaCha20-Poly1305 Algorithm or CBC-EtM 
Algorithm is active. It subsequently verifies whether Strict Key Exchange is 
enabled. If a target is identified as vulnerable, it indicates that the target 
supports either of the vulnerable algorithms and lacks support for Strict Key 
Exchange.

Solution

Customers are advised to refer to the individual vendor advisory for their 
operating system and install the patch released by the vendor. For more 
information regarding the vulnerability, please refer to Terrapin Vulnerability



Patch:



Following are links for downloading patches to fix the vulnerabilities:

OpenWall Security Advisory

Impact

Successful exploitation of the vulnerability may allow an attacker to downgrade 
the security of an SSH connection when using SSH extension negotiation. The 
impact in practice heavily depends on the supported extensions. Most commonly, 
this will impact the security of client authentication when using an RSA public 
key.

CVEs

CVE-2023-48795

Results

SSH Prefix Truncation Vulnerability (Terrapin) detected on port: 22

ChaCha20-Poly1305 Algorithm Support: True

CBC-EtM Algorithm Support: False

Strict Key Exchange algorithm enabled: False

EVM Report

Yes

EVM Risk Score

4.9

Host Details

Host

192.168.30.2

IP Address

192.168.30.2

Operating System

IBM OS/390

Tier

T3

FQDN



Port

22

Protocol

tcp




Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of 

Re: Encryption and decryption - processor or TCPIP

[Eric D Rossman]

You are correct. It's on the same piece of silicon NOW. My original point is 
still good. I don't understand why there is a focus on a minor detail of the 
physical layout of the chip.

Correcting my original statement.
"The CPACF is a PIECE OF THE CP that runs in lockstep with the CP that invokes 
it. So, it is does cost general CP but much less than implementing it in 
millicode."

Eric Rossman

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Martin Packer
Sent: Thursday, January 25, 2024 10:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP

If I'm interpreting the z16 materials right it's within the core's area.

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

Re: Encryption and decryption - processor or TCPIP

[Martin Packer]

If I’m interpreting the z16 materials right it’s within the core’s area.

From: IBM Mainframe Discussion List  on behalf of 
Eric D Rossman 
Date: Thursday, 25 January 2024 at 15:07
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [EXTERNAL] Re: Encryption and decryption - processor or TCPIP
> Actually, every processor core includes its own CPACF coprocessor section.
> In other words, CPACF is "on core."

It's a fine distinction. My background is in HW so I describe it as separate 
from the "CP" proper, even though it is on the same chip.

Eric Rossman

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

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

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

Re: Encryption and decryption - processor or TCPIP

[Eric D Rossman]

> Actually, every processor core includes its own CPACF coprocessor section.
> In other words, CPACF is "on core."

It's a fine distinction. My background is in HW so I describe it as separate 
from the "CP" proper, even though it is on the same chip.

Eric Rossman

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

Re: pax and extended attributes

[Colin Paice]

Someone told me to use the following to get all the attributes

You create a file using

pax -o saveext -wf *pax_file_name files_to_add*

and

pax -ppx -rf *pax_file_name*

to extract the files.

On Thu, 25 Jan 2024 at 13:49, Styles, Andy (CIO GS - Core Infrastructure
& IT Operations ) <00d68f765d25-dmarc-requ...@listserv.ua.edu> wrote:

> Classification: Public
>
> You probably need the -p e switch:
>
>e
> Preserves the user ID, group ID, file mode, access
> time,
> modification time, extended attributes, and ACL
> entries. Prior
> to z/OS 1.8, audit flags and file format (line end)
> attributes
> were not restored because they are not available in any
> archive format. The extended attributes are the apsl
> flags
> that are set by the extattr command. A pax format
> archive can
> be used to store the audit flags and file format, and
> -p e
> will restore them when available.
>
>
> Andy Styles
> z/Series Systems Programmer
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Radoslaw Skorupka
> Sent: Thursday, January 25, 2024 1:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: pax and extended attributes
>
> *** This email is from an external source - be careful of attachments and
> links. Please report suspicious emails ***
>
> I have to move some directory trees from one file system location to
> another.
> The tree is rather complex (dozen directories, hundreds files) and some
> files do have extended attributes.
> My goal is to preserve all the metadata like files ownership, FSP, ACL,
> tags, audit flags, etc.
>
> I tried to use pax
> pax -wvf /u/pack1 -x pax .(current directory)
> and then
> pax -rvf /u/pack1 . (also current directory, but different one)
>
> It looks OK, but a flag is lost.
>
> The user is UID 0 (after su command) and has READ authority to
> BPX.FILEATTR.*
>
> Did I miss something?
>
>
> Finally I used copytree, but this tool does not allow to create temporary
> packages, which is some disadvantage in my scenario.
>
> Or maybe there is just another tool to accomplish the task?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ.
> Registered in Scotland no. SC95000. Telephone: 0131 225 4555.
>
> Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN.
> Registered in England and Wales no. 2065. Telephone 0207626 1500.
>
> Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ.
> Registered in Scotland no. SC327000. Telephone: 03457 801 801.
>
> Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street,
> London EC2V 7HN. Registered in England and Wales no. 10399850.
>
> Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25
> Gresham Street, London EC2V 7HN. Registered in England and Wales no.
> 11722983.
>
> Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets
> plc are authorised by the Prudential Regulation Authority and regulated by
> the Financial Conduct Authority and Prudential Regulation Authority.
>
> Scottish Widows Schroder Personal Wealth Limited is authorised and
> regulated by the Financial Conduct Authority.
>
> Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned
> subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate
> Markets Wertpapierhandelsbank GmbH has its registered office at
> Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is
> registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank
> Corporate Markets Wertpapierhandelsbank GmbH is supervised by the
> Bundesanstalt für Finanzdienstleistungsaufsicht.
>
> Halifax is a division of Bank of Scotland plc.
>
> HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in
> Scotland no. SC218813.
>
>
>
> This e-mail (including any attachments) is private and confidential and
> may contain privileged material. If you have received this e-mail in error,
> please notify the sender and delete it (including any attachments)
> immediately. You must not copy, distribute, disclose or use any of the
> information in it or any attachments. Telephone calls may be monitored or
> recorded.
>
>
> --
> 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 

Re: New SSH vulnerability

[Allan Staller]

Classification: Confidential

It does take some time for the fixes to be developed, tested and distributed.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Thursday, January 25, 2024 8:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: New SSH vulnerability

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Looks like a fairly new SSH vulnerability has surfaced...Anyone figure out a 
local remediation for this yet?   As per usual, IBM is mum.   There is no 
fixing PTF yet based on what I see in ResourceLink.


QID

38913

Severity

HIGH

Definition

SSH Prefix Truncation Vulnerability (Terrapin)

Description

The Terrapin attack exploits weaknesses in the SSH transport layer protocol in 
combination with newer cryptographic algorithms and encryption modes introduced 
by OpenSSH over 10 years ago. Since then, these have been adopted by a wide 
range of SSH implementations, therefore affecting a majority of current 
implementations.





QID Detection Logic (Unauthenticated):



This detection attempts to start the SSH key exchange process and examines 
whether either of the vulnerable ChaCha20-Poly1305 Algorithm or CBC-EtM 
Algorithm is active. It subsequently verifies whether Strict Key Exchange is 
enabled. If a target is identified as vulnerable, it indicates that the target 
supports either of the vulnerable algorithms and lacks support for Strict Key 
Exchange.

Solution

Customers are advised to refer to the individual vendor advisory for their 
operating system and install the patch released by the vendor. For more 
information regarding the vulnerability, please refer to Terrapin Vulnerability



Patch:



Following are links for downloading patches to fix the vulnerabilities:

OpenWall Security Advisory

Impact

Successful exploitation of the vulnerability may allow an attacker to downgrade 
the security of an SSH connection when using SSH extension negotiation. The 
impact in practice heavily depends on the supported extensions. Most commonly, 
this will impact the security of client authentication when using an RSA public 
key.

CVEs

CVE-2023-48795

Results

SSH Prefix Truncation Vulnerability (Terrapin) detected on port: 22

ChaCha20-Poly1305 Algorithm Support: True

CBC-EtM Algorithm Support: False

Strict Key Exchange algorithm enabled: False

EVM Report

Yes

EVM Risk Score

4.9

Host Details

Host

192.168.30.2

IP Address

192.168.30.2

Operating System

IBM OS/390

Tier

T3

FQDN



Port

22

Protocol

tcp




Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

New SSH vulnerability

[Jousma, David]

Looks like a fairly new SSH vulnerability has surfaced…Anyone figure out a 
local remediation for this yet?   As per usual, IBM is mum.   There is no 
fixing PTF yet based on what I see in ResourceLink.


QID

38913

Severity

HIGH

Definition

SSH Prefix Truncation Vulnerability (Terrapin)

Description

The Terrapin attack exploits weaknesses in the SSH transport layer protocol in 
combination with newer cryptographic algorithms and encryption modes introduced 
by OpenSSH over 10 years ago. Since then, these have been adopted by a wide 
range of SSH implementations, therefore affecting a majority of current 
implementations.





QID Detection Logic (Unauthenticated):



This detection attempts to start the SSH key exchange process and examines 
whether either of the vulnerable ChaCha20-Poly1305 Algorithm or CBC-EtM 
Algorithm is active. It subsequently verifies whether Strict Key Exchange is 
enabled. If a target is identified as vulnerable, it indicates that the target 
supports either of the vulnerable algorithms and lacks support for Strict Key 
Exchange.

Solution

Customers are advised to refer to the individual vendor advisory for their 
operating system and install the patch released by the vendor. For more 
information regarding the vulnerability, please refer to Terrapin Vulnerability



Patch:



Following are links for downloading patches to fix the vulnerabilities:

OpenWall Security Advisory

Impact

Successful exploitation of the vulnerability may allow an attacker to downgrade 
the security of an SSH connection when using SSH extension negotiation. The 
impact in practice heavily depends on the supported extensions. Most commonly, 
this will impact the security of client authentication when using an RSA public 
key.

CVEs

CVE-2023-48795

Results

SSH Prefix Truncation Vulnerability (Terrapin) detected on port: 22

ChaCha20-Poly1305 Algorithm Support: True

CBC-EtM Algorithm Support: False

Strict Key Exchange algorithm enabled: False

EVM Report

Yes

EVM Risk Score

4.9

Host Details

Host

192.168.30.2

IP Address

192.168.30.2

Operating System

IBM OS/390

Tier

T3

FQDN



Port

22

Protocol

tcp




Dave Jousma
Vice President | Director, Technology Engineering





This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: Unknopwn device type 3030200F

[80]

Thanks Attila.


*De :* Attila Fogarasi [mailto:fogar...@gmail.com]
*Envoyé :* jeudi 25 janvier 2024 à 12:17
*Pour :* IBM-MAIN@LISTSERV.UA.EDU
*Objet :* Unknopwn device type 3030200F


3030200F means shared 3390, documented in UCBTYP in Data Areas manual or
look in the UCB macro.  DFSMS manual didn't bother to document the shared
bit :)

On Thu, Jan 25, 2024 at 9:01 PM MANCINI Frédéric (80) <
frederic.manc...@dgfip.finances.gouv.fr> wrote:


Hello,
We are trying to recover a catalog's contents by using the output of a
previous LISTCAT.
The device type 3030200F does not seem to be documented
(
https://www.ibm.com/docs/en/zos/2.3.0?topic=fields-device-type-translate-table
).
Does anyone know the corresponding device ?
Regards,
Frédéric Mancini

--
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: OT-ish: Very old IBM hardware & manuals available

[Seymour J Metz]

I started on a 650, and that had a 2,000 word drum. The 305, before my time, 
had a 2400 character drum. I'm not aware of any IBM drum smaller than that.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Leonard D Woren 
Sent: Thursday, January 25, 2024 12:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OT-ish: Very old IBM hardware & manuals available

Maybe contact the Computer History Museum https://computerhistory.org/
.  They probably have the resources to ship anything they're
interested in.

Their collection includes IBM hardware that predates any of us having
seen a digital computer.  It's been quite a while since I was there,
but they were working on fixing up an IBM drum storage device which I
think was the size of beer keg and held something like 550 bytes, no
typo, or maybe it was a few kbytes.

/Leonard


Robert Prins wrote on 1/23/2024 7:57 AM:
> Hi all,
>
> My father worked for IBM in the Netherlands for more than 30 years,
> starting as a CE in the late 1950'ies. Last year he was diagnosed with
> Alzheimer, and over the past few months my siblings and me have been
> emptying his apartment and storage room, and we've come across a sizeable
> quantity of IBM "stuff", from manuals for the 650 to old square cm
> "integrated circuits" and even a magnetic core memory card. My siblings
> weren't in the least interested in any of it, so I took it, and although
> it's nice to look at, our house is already full enough as it is, so...
>
> If anyone thinks they can offer a good home to these things, and I will,
> hopefully soon, put pictures of everything that surfaces on my website,
> feel free to contact me off this list and we can take it from there. You'll
> most definitely be paying for shipping (from Lithuania), and based on what
> I'm going to find out on fleabay, I might ask for a bit more.
>
> Robert


--
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: pax and extended attributes

[Styles, Andy (CIO GS - Core Infrastructure & IT Operations )]

Classification: Public

You probably need the -p e switch:

   e
Preserves the user ID, group ID, file mode, access time,
modification time, extended attributes, and ACL entries. 
Prior
to z/OS 1.8, audit flags and file format (line end) 
attributes
were not restored because they are not available in any
archive format. The extended attributes are the apsl flags
that are set by the extattr command. A pax format archive 
can
be used to store the audit flags and file format, and -p e
will restore them when available.


Andy Styles
z/Series Systems Programmer

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Thursday, January 25, 2024 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: pax and extended attributes

*** This email is from an external source - be careful of attachments and 
links. Please report suspicious emails ***

I have to move some directory trees from one file system location to another.
The tree is rather complex (dozen directories, hundreds files) and some files 
do have extended attributes.
My goal is to preserve all the metadata like files ownership, FSP, ACL, tags, 
audit flags, etc.

I tried to use pax
pax -wvf /u/pack1 -x pax .(current directory)
and then
pax -rvf /u/pack1 . (also current directory, but different one)

It looks OK, but a flag is lost.

The user is UID 0 (after su command) and has READ authority to
BPX.FILEATTR.*

Did I miss something?


Finally I used copytree, but this tool does not allow to create temporary 
packages, which is some disadvantage in my scenario.

Or maybe there is just another tool to accomplish the task?

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555.

Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. 
Registered in England and Wales no. 2065. Telephone 0207626 1500.

Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC327000. Telephone: 03457 801 801.

Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London 
EC2V 7HN. Registered in England and Wales no. 10399850.

Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham 
Street, London EC2V 7HN. Registered in England and Wales no. 11722983.

Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are 
authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority and Prudential Regulation Authority.

Scottish Widows Schroder Personal Wealth Limited is authorised and regulated by 
the Financial Conduct Authority.

Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned 
subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 
6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht 
Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets 
Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für 
Finanzdienstleistungsaufsicht.

Halifax is a division of Bank of Scotland plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.



This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.


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

pax and extended attributes

[Radoslaw Skorupka]

I have to move some directory trees from one file system location to 
another.
The tree is rather complex (dozen directories, hundreds files) and some 
files do have extended attributes.
My goal is to preserve all the metadata like files ownership, FSP, ACL, 
tags, audit flags, etc.


I tried to use pax
pax -wvf /u/pack1 -x pax .    (current directory)
and then
pax -rvf /u/pack1 . (also current directory, but different one)

It looks OK, but a flag is lost.

The user is UID 0 (after su command) and has READ authority to 
BPX.FILEATTR.*


Did I miss something?


Finally I used copytree, but this tool does not allow to create 
temporary packages, which is some disadvantage in my scenario.


Or maybe there is just another tool to accomplish the task?

--
Radoslaw Skorupka
Lodz, Poland

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

Re: Unknopwn device type 3030200F

[Attila Fogarasi]

3030200F means shared 3390, documented in UCBTYP in Data Areas manual or
look in the UCB macro.  DFSMS manual didn't bother to document the shared
bit :)

On Thu, Jan 25, 2024 at 9:01 PM MANCINI Frédéric (80) <
frederic.manc...@dgfip.finances.gouv.fr> wrote:

> Hello,
> We are trying to recover a catalog's contents by using the output of a
> previous LISTCAT.
> The device type 3030200F does not seem to be documented
> (
> https://www.ibm.com/docs/en/zos/2.3.0?topic=fields-device-type-translate-table
> ).
> Does anyone know the corresponding device ?
> Regards,
> Frédéric Mancini
>
> --
> 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

Unknopwn device type 3030200F

[80]

Hello,
We are trying to recover a catalog's contents by using the output of a 
previous LISTCAT.
The device type 3030200F does not seem to be documented 
(https://www.ibm.com/docs/en/zos/2.3.0?topic=fields-device-type-translate-table).

Does anyone know the corresponding device ?
Regards,
Frédéric Mancini

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

Re: Encryption and decryption - processor or TCPIP

[Peter Sylvester]

Hi,

there is another possibilty for a delay in TLS session setup:

When you connect in clear to a TN3270 server and then have told your client to use STARTTLS. This 
may be a fast initial solution in case when your firewall cerberos :-) cannot rapidly a new port, 
i.e. 992.


Best

/PS

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