Off course they're files; they just aren't in EUnix file systems. Part of
the file contents for load modules is in the directory entries, and Fetch
relies on those data. As for program objects, if I knew they'd have to
shoot me; I don't have FAMS.
The issue on STEPLIB is simply that IBM doesn't see a business case to
support it. Part of that support would be an update to APF and program
control for paths. Would you want individual executables in STEPLIB, or
only directories? RFE?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
________________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf
of Paul Gilmartin <0000042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Saturday, January 13, 2024 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Technical Reason? - Why you can't encrypt load libraries
(PDSE format)?
On Sat, 13 Jan 2024 18:06:24 +0100, Radoslaw Skorupka wrote:
I can imagine technical reason to not encrypt such libraries.
However encryption is a kind of data protection. Data. Not programs.
But some load modules/program objects aren't really files. As Ifond
out to my dismay as a novice when I tried to use IEBGENER to copy
a load module to a different PDS.
But UNIX program objects are "really files". "cp -p" works on then.
But content Supervision relies heavily on the elaborate format. Part
of the reason that UNIX directories don't work in STEPLIB
concatenation. (Idea?)
What about Format preserving encryption?
Should the directory be encrypted likewise?
What about driver-level encryption of virtual DASD?
Unload it and encrypt the archive?
What authority should be needed to use an encrypted program?
W dniu 13.01.2024 o 17:28, Steve Estle pisze:
Everyone,
Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and
despite the fact such functionality has been out for years by IBM to do
this, it is quite surprising how many software vendors when you contact
them they have no clue what you're talking about - that is a complete aside
- I'm not going to name vendors here but if you want some examples you can
contact me offline.
My true reason for composing this is that we've discovered the
inability to encrypt load libraries - even in PDSE format. I've yet to get
a straight answer from IBM on why this is?... Is this a "giant" technical
hurdle for IBM? Or is it just cause there hasn't been anyone who raised
the need yet? If the latter does this capability interest others here if I
were to raise as an IBM idea - would you vote for it?
I know this seems innocuous, but we'd like to encrypt as much as
possible in our environment and due to Top Secret deficiencies we have to
encrypt at high level qualifier level (HLQ) (all or nothing under each HLQ
unfortunately). Given we have load module libraries under many differ
HLQ's this is posing difficulties in moving forward with our rollout when
an HLQ does have one or more load module libraries as part of that HLQ.
You can only imagine the pain of renaming a load library given all the JCL,
etc that is referencing that library name.
Also, while encrypting load module libraries might seem a little far
fetched, there are of course many malicious viruses that have been launched
by injecting code into a suspecting piece of code.
So two questions:
1. Why has IBM not already provided such functionality - can anyone
speak to the technical hurdles to provide?
2. If I were to submit an IBM idea, can I count on this community for
some backing here to help in upvoting such an idea submission?
--
gil
----------------------------------------------------------------------
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
