I think that another major consideration not to encrypt programs is
performance. Racf exits, for example, are not getting control of program
calls. Pervasive encryption is done in bulks, programs may be called
thousands of time during data processing.
*| **Itschak Mugzach | Director | SecuriTeam
Interesting discussion. Some thoughts.
First, it's not "Pervasive Encryption" you're talking about. It's IBM z/OS data
set encryption (DSE). PE is the IBM encryption strategy. When data set
encryption came along, IBM kept calling it PE, but it's just part of PE (the
rest of which hasn't
That "low level block processor" is Media Manager Services (MMS) and also
SDM (System Data Mover) which is heavily used by all the performance
oriented large volume data accessors (Db2, IMS, XRC,etc).
On Sun, Jan 14, 2024 at 4:48 PM Seymour J Metz wrote:
> There used to be a low level bock
Is the problem that they cannot be encrypted or that they cannot be executed
when in encrypted format?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message:
It is indeed a technical reason: PDS and PDSE datasets cannot be
Extended-Format. Pervasive Encryption requires Extended-Format. The
restrictions on Extended-Format have been problematic for the past decade,
so presumably not easy to fix. A few other dataset types are also affected
(such as
There used to be a low level bock processor used by paging and VSAM, operating
on CI formatted data via STARTIO. I would guess that if it still exists then
Fetch uses it for program objects.
For load modules it would still be CCWs, probably via STARTIO.
--
Shmuel (Seymour J.) Metz
On Sat, 13 Jan 2024 at 21:48, Seymour J Metz wrote:
> Unless IBM has enhanced z/OS to allow EXEC PGM=path, I wouldn't expect a
> program object in DSFS to work.
>
> STEPLIB is a general facility, unrelated to HLASM.
I think he was referring to HLASM's use of directories for maclibs.
> It's
Unless IBM has enhanced z/OS to allow EXEC PGM=path, I wouldn't expect a
program object in DSFS to work.
STEPLIB is a general facility, unrelated to HLASM. It's essentially a tasklib
provided by the Initiator and doesn't depend on any access method.
--
Shmuel (Seymour J.) Metz
On Sat, 13 Jan 2024 23:38:23 +, Seymour J Metz wrote:
>
>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?
My gues is that low level services used by Fetch, e.g., EXCP, STARTIO, do not
support pervasive encryption.
What about windowed access to VSAM?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Programs are data.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
From: IBM Mainframe Discussion List on behalf of
Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
Sent:
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
IBM/MS-DOS 6 stored compressed programs by having a decompression stub and
the compressed program as the remainder of the file data.
On Sat, Jan 13, 2024 at 1:50 PM Grant Taylor <
023065957af1-dmarc-requ...@listserv.ua.edu> wrote:
> On 1/13/24 13:39, Gibney, Dave wrote:
> > It should be
Out of curiosity, does that means that the CSFDLL functions do not create a
linkage stack entry before calling the true routines/
On Fri, 12 Jan 2024 14:23:54 + Eric D Rossman wrote:
:>There is no documentation because this is not a supported interface. It has
been suggested in passing but
On 1/13/24 13:39, Gibney, Dave wrote:
It should be obvious, but as a practical matter, you can't encrypt
the modules that do the decryption and it also follows that you can't
encrypt the modules that provide the execution environment (z/OS)
for these modules.
I would like to agree with you.
It should be obvious, but as a practical matter, you can't encrypt the modules
that do the decryption and it also follows that you can't encrypt the modules
that provide the execution environment (z/OS) for these modules.
--
On 1/13/24 11:06, Radoslaw Skorupka wrote:
However encryption is a kind of data protection.
Conversely encryption is a kind of data authentication / verification.
Data. Not programs.
Programs are special data used to manipulate / act on other data.
--
Grant. . . .
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
1.
Restrictions for encrypted data sets
-
System data sets (such as Catalogs, SMS control data sets, SHCDS, HSM
data sets) must not be encrypted, unless otherwise specified in
product documentation.
-
Data sets used during IPL must not be encrypted.
Page
I can imagine technical reason to not encrypt such libraries.
However encryption is a kind of data protection. Data. Not programs.
--
Radoslaw Skorupka
Lodz, Poland
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
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
You originally asked about the syntax error message.
The syntax of the command used was incorrect, and I think the syntax error
message was pretty reasonable.
F HZSPROC,ADDREPLACE,CHECK=(IBMUSS,USS_HFS_DETECTED),USS=YES
ASA101I SYNTAX ERROR: WAS SEEN, WHERE ONE OF 826
(CHECKROUTINE DATE EXEC
>From one of the posts, it wasn't clear if the OP realized that the entry
>descriptor is at the end of the entry, not at the beginning.
If you're not traversing stack sections, complications related to header and
trailer don't tend to come into play.
Consider posting the entire linkage stack
23 matches
Mail list logo
