Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

[Phil Smith III]

Peter Sylvester wrote, in part:

>There is a difference between what you must set and what you must

>verify. 5280/3280 is clear (IMO) about that.

>when you verify a cert, AND you know about the extension, you just

>verify the extension and don't care about the critical bit

>Since the error message seems to indicate that the extension is known,

>the verifier has no reason to checjk the criticality bit.

 

By "when you verify a cert" you mean gsk, and that it shouldn't care about the 
critical bit?

 

>>The fix was to update the root certificate used by the server to add

>>the required Critical value for Basic Constraints (henceforth "BC" as

>>a shorthand).

 

>The RFC path validation does not usea selfsignedroot certificate. The

>only necessary thing for an implementation is to have an association

>between a subject an a public key.

>A self signed cert is just handy.

 

>>This happened again here this week when a certificate was updated

>>(someone used the wrong internal CA, which was old). Once we got it

>>straightened out, I started wondering why this only happened once we

>>added TLSv1.3 support. Some reading of RFC5280 (which obsoleted 3280)

>>suggests that a PKIX-compliant certificate should ALWAYS be rejected

>>if not BC. But this doesn't seem to be true until we add the TLSv1.3

>>support.

what is suggesting this?

 

If by "this" you mean "what is suggesting 'But this doesn't seem to be true 
until we add the TLSv1.3 support'" then it's that the old version, which 
doesn't do TLSv1.3, didn't get the BC error with the same cert.

 

>SNI is used to identify a server, and in particular, the cert (chain)

>to be presented to the client.

 

Right, I know.I was just noting that this was another change between versions, 
in case there was some interaction.

 

>Does you product work with TLS 1.2?

 

Yes. Has for years. Both old and new versions.

 

So to recap, my perception is that if the client doesn't say "I can do 
TLSv1.3", BC doesn't matter; if it does say so, BC matters.

 

I feel dense, but I'm not sure what to conclude from what you wrote-whether 
you're suggesting that gsk is doing something wrong or not. Or maybe you hadn't 
presented a conclusion yet, pending my answers above!

 

Appreciate the input, hoping for more.

 

.phsiii


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

Re: Migrating Loadlibs from PDSE to PDS?

[Peter Vels]

I recommend Prycroft's REVIEW which displays Program Management version
(column V below)

SYS1.SIEALNKE  Row 1 of
188
Command ===>Scroll ===>
CS
  RealName Alias-Name  Size AC AMd At RU V Non-0-EP Save-Timestamp
User/Job
. ADRDSFSI  5K 11D0 00 A31RN 2  19-05-07 13:50
RV0591PB
. CBREFSI  43K AB7A 00 A64 NM RN 42d   38F0 19-05-07 13:47
RV0591PB
. CFZR24C   1K  3E8 01 A31 NM RN 2  19-09-25 07:43
WBEMPAX8
. CPOJLNCH 15K 3BC8 01 A31 NM3 d19-05-07 14:04
RV0591PD
. CRURRAP  SSI=170041079FA0 00 PG2  19-05-07 13:44
RV0591PB
. CRURRSV  SSI=17004107DF30 00 PG2  19-05-07 13:44
RV0591PB
. CSFDLL3X 98K1866C 00 A31 NM RN 3 d19-08-26 15:20
PKCS113
. CSFDLL31122K1E6AC 00 A31 NM RN 3 d19-08-26 15:20
PKCS113
. CSFDLL64121K1E330 00 A64 NM RN 42d19-08-26 15:20
PKCS113


The "42" is actually 4 followed by a superscripted 2. See
https://www.prycroft6.com.au/REVIEW/revfaq.html for more details.

Peter

On Sun, 10 Dec 2023 at 11:37, Seymour J Metz  wrote:

> IEBCOPY is the right tool for the program objects that can be converted.
> There re z/OS facilities that won't work with load modules.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Steve Estle 
> Sent: Saturday, December 9, 2023 8:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Migrating Loadlibs from PDSE to PDS?
>
> Seasons Greetings all,
>
> I know this might sound like a strange request, but we are exploring what
> if any options there are to migrate load libraries from PDSE (version 1 or
> 2) back to traditional basic PDS's.  It appears this is highly restricted
> based on my experiences trying to perform via IEBCOPY and ISPF 3.3 (which
> just involkes IEBCOPY under the covers)?  Any thoughts/experiences on ways
> to do this or is it just one of those once you are there the "train don't
> go in reverse" situations?
>
> Thanks in advance for any ideas/suggestions.
>
> Steve Estle
>
> --
> 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

Sources for wiki UCB article

[Seymour J Metz]

Can anybody cite some good sources to cite for dynamic UCBs? ideally it should 
be a secondary source, due to wiki policy, and not assume to much background. 
If there's a concise definition that I can quote in the citation, that would be 
great.

I want to reinstate the material dropped by edit 
,
 and need some citations to make it stick. I probably need to add some 
citations fror PAV as well.

I no book or refereed paper is available, a redbook would probably do.

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

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

Re: Migrating Loadlibs from PDSE to PDS?

[Seymour J Metz]

IEBCOPY is the right tool for the program objects that can be converted. There 
re z/OS facilities that won't work with load modules.



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


From: IBM Mainframe Discussion List  on behalf of 
Steve Estle 
Sent: Saturday, December 9, 2023 8:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Migrating Loadlibs from PDSE to PDS?

Seasons Greetings all,

I know this might sound like a strange request, but we are exploring what if 
any options there are to migrate load libraries from PDSE (version 1 or 2) back 
to traditional basic PDS's.  It appears this is highly restricted based on my 
experiences trying to perform via IEBCOPY and ISPF 3.3 (which just involkes 
IEBCOPY under the covers)?  Any thoughts/experiences on ways to do this or is 
it just one of those once you are there the "train don't go in reverse" 
situations?

Thanks in advance for any ideas/suggestions.

Steve Estle

--
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: ... FLOWASM and ASMA435I

[Ed Jaffe]

On 6/9/2021 7:19 AM, Rob Scott wrote:

Response from HLASM Development (Thanks Jonathan Scott) :

If an input exit supplies the record (which happens in this case, even if the 
record is unchanged), the source record number information for error message 
purposes (which may be different from the number of records provided by the 
exit) needs to be filled in by the exit routine in field AXPRELREC.

I will send info to Ed and see if FLOWASM can be enhanced.


Only took 2/12 years (to the day), but the "Zero Record Number in ASMA 
Messages" problem is now fixed in FLOWASM.


A new version is available here: 
https://phoenixsoftware.com/ftp/demo/flowasm.xmi (Ver 2, Rel 1).


It supports everything from before (including z/OS UNIX input), adds 
support for a new REXX-like subroutine label syntax, and uses newer 
faster instructions (COMPARE AND BRANCH, MOVE HALFWORD IMMEDIATE, etc).


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Assembler optimization OPTION

[Bernd Oppolzer]

There were different situations.

First of all, a co-worker on the project (from Kyndryl) helped us by 
identifying the modules which were in trouble.
I guess he used special traces or performance reports; don't know which 
sort of reports exactly. But he found

the SIIS hits somehow.

Then, when I knew the modules to examine, I found different situations 
... some examples:


1) IBM macros with inline parameter lists with SIIS issues (TIME for 
example, but others, too)

- with register parameters mostly
2) home grown macros with the same problem
3) LOOPs built by home grown SP macros with decimal control variables 
inside the instruction stream (!)
4) internal subroutines built by local macros where local static data 
immediately followed the code (same cache line)

5) other (more sophisticated) problems

I will tell you briefly what I did:

1) change the macros to list/execute form, as suggested by IBM, or 
switch to other (home grown) services
2) same as 1) or fix the macros to use a separate (workarea) DSECT, 
which is present in all our modules

3) fix the SP macros
4) if possible, move the data to the workarea DSECT; if not, enter some 
space before the data, so that the

data resides in the next cache line (256 bytes)
5) if possible, separate data from the instructions by moving it to the 
workarea which is provided by the
(already existent) startup macro; this also allows for baseless coding 
in most situations


Because the modules affected are part of the basic IMS framework of the 
customer and carry the daily
IMS dialog services with some thousand users, these modifications had to 
be tested carefully, before
putting them into production. The project started in the beginning of 
2021 and was terminated successfully

half a year later with (almost) no problems or downtimes.

HTH, kind regards

Bernd


Am 09.12.2023 um 15:38 schrieb Mike Schwab:

Putting DS and modified DCs into a separate area?

On Sat, Dec 9, 2023 at 5:17 AM Bernd Oppolzer 
wrote:


Hi,

there is no such option;
this is not possible, because with ASSEMBLER, the programmer has full
control about where he or she puts the information elements,
be it static data or code. There is no magic engine like the optimizer
with compilers which can do anything about that.

This said:

I had a project in 2021 with a large customer which had very old
ASSEMBLER programs from the 1980s, which had heavy SIIS problems
(store into instruction stream) which had to be resolved. I found out
that some of them can easily be resolved by the use of clever macros
which separate the static data from the code (by putting them in a
different CSECT or DSECT). The details are too complicated to discuss here,
but in the end, the changes to the code were minimal. And in the end, we
achieved our project goals in time and budget.

HTH, kind regards

Bernd


Am 08.12.2023 um 20:29 schrieb Ituriel do Neto:

Hello everyone,

Recently i have seen some discussions related to assembler performance

to use the L1 cache of the processor better and not mixing instructions and
data.

Can you enlighten me which assembler option can be used for this purpose?

Thanks in advance


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer

--
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: Migrating Loadlibs from PDSE to PDS?

[Ed Jaffe]

On 12/9/2023 5:24 AM, Steve Estle wrote:

Seasons Greetings all,

I know this might sound like a strange request, but we are exploring what if any options 
there are to migrate load libraries from PDSE (version 1 or 2) back to traditional basic 
PDS's.  It appears this is highly restricted based on my experiences trying to perform 
via IEBCOPY and ISPF 3.3 (which just involkes IEBCOPY under the covers)?  Any 
thoughts/experiences on ways to do this or is it just one of those once you are there the 
"train don't go in reverse" situations?


It's a smooth transition if you're copying program object format 2 or 
lower. Anything over that and you might be losing something important. 
In some cases, you will get warnings or errors from the binder (which is 
called by IEBCOPY to rebind the modules).


The binder produces a save operation summary that tells you which format 
is used. For example:


|SAVE OPERATION SUMMARY:
|
|   MEMBER NAME modname
|   LOAD LIBRARY    data.set.name
|   PROGRAM TYPE    PROGRAM OBJECT(FORMAT 5) <-- here!
|   VOLUME SERIAL   volser
|   DISPOSITION ADDED NEW
|   TIME OF SAVE    15.50.30  NOV 29, 2023

After the fact, you can use AMBLIST LISTLOAD to show this information to 
you:


|MODULE SSI:    NONE
|APFCODE:   
|RMODE: ANY
|LONGPARM:  NO
|PO FORMAT: 5 <-- here!
|OS COMPAT LEVEL:   z/OSV2R1
|XPLINK:    NO

Sadly, the ISPF member list for a program object library does not 
display PO format along with the other load module attributes. If it 
did, you could sort on that field and easily see where you stand.


It shows SSI which these days useless info (IMHO) but not PO format 
which is important. They never improve anything without an RFE asking 
for it. [sigh]


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: Assembler optimization OPTION

[Paul Gilmartin]

On Sat, 9 Dec 2023 12:17:01 +0100, Bernd Oppolzer  wrote:
>
>there is no such option;
>this is not possible, because with ASSEMBLER, the programmer has full
>control about where he or she puts the information elements,
>be it static data or code. There is no magic engine like the optimizer
>with compilers which can do anything about that.
> 
Given that cache line size is model dependent, or someday might become so,
it would be valuable if OPTABLE set a GBLA containing that value
to be used as an operand of ORG, etc.

-- 
gil

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

Re: Migrating Loadlibs from PDSE to PDS?

[Mike Schwab]

Limits are based on what compiler you used.  Cobol 5+ uses PDSE features
that can't be moved into a PDS.

On Sat, Dec 9, 2023 at 7:24 AM Steve Estle  wrote:

> Seasons Greetings all,
>
> I know this might sound like a strange request, but we are exploring what
> if any options there are to migrate load libraries from PDSE (version 1 or
> 2) back to traditional basic PDS's.  It appears this is highly restricted
> based on my experiences trying to perform via IEBCOPY and ISPF 3.3 (which
> just involkes IEBCOPY under the covers)?  Any thoughts/experiences on ways
> to do this or is it just one of those once you are there the "train don't
> go in reverse" situations?
>
> Thanks in advance for any ideas/suggestions.
>
> Steve Estle
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Assembler optimization OPTION

[Mike Schwab]

Putting DS and modified DCs into a separate area?

On Sat, Dec 9, 2023 at 5:17 AM Bernd Oppolzer 
wrote:

> Hi,
>
> there is no such option;
> this is not possible, because with ASSEMBLER, the programmer has full
> control about where he or she puts the information elements,
> be it static data or code. There is no magic engine like the optimizer
> with compilers which can do anything about that.
>
> This said:
>
> I had a project in 2021 with a large customer which had very old
> ASSEMBLER programs from the 1980s, which had heavy SIIS problems
> (store into instruction stream) which had to be resolved. I found out
> that some of them can easily be resolved by the use of clever macros
> which separate the static data from the code (by putting them in a
> different CSECT or DSECT). The details are too complicated to discuss here,
> but in the end, the changes to the code were minimal. And in the end, we
> achieved our project goals in time and budget.
>
> HTH, kind regards
>
> Bernd
>
>
> Am 08.12.2023 um 20:29 schrieb Ituriel do Neto:
> > Hello everyone,
> >
> > Recently i have seen some discussions related to assembler performance
> to use the L1 cache of the processor better and not mixing instructions and
> data.
> >
> > Can you enlighten me which assembler option can be used for this purpose?
> >
> > Thanks in advance
> >
> >
> > Best Regards
> >
> > Ituriel do Nascimento Neto
> > z/OS System Programmer
> >
> > --
> > 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
>


-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Migrating Loadlibs from PDSE to PDS?

[Mark Jacobs]

The ADRDSSU COPY command with the CONVERT option will do what you're looking 
for.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com


On Saturday, December 9th, 2023 at 8:24 AM, Steve Estle  
wrote:


> Seasons Greetings all,
> 
> I know this might sound like a strange request, but we are exploring what if 
> any options there are to migrate load libraries from PDSE (version 1 or 2) 
> back to traditional basic PDS's. It appears this is highly restricted based 
> on my experiences trying to perform via IEBCOPY and ISPF 3.3 (which just 
> involkes IEBCOPY under the covers)? Any thoughts/experiences on ways to do 
> this or is it just one of those once you are there the "train don't go in 
> reverse" situations?
> 
> Thanks in advance for any ideas/suggestions.
> 
> Steve Estle
> 
> --
> 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

Migrating Loadlibs from PDSE to PDS?

[Steve Estle]

Seasons Greetings all,

I know this might sound like a strange request, but we are exploring what if 
any options there are to migrate load libraries from PDSE (version 1 or 2) back 
to traditional basic PDS's.  It appears this is highly restricted based on my 
experiences trying to perform via IEBCOPY and ISPF 3.3 (which just involkes 
IEBCOPY under the covers)?  Any thoughts/experiences on ways to do this or is 
it just one of those once you are there the "train don't go in reverse" 
situations?

Thanks in advance for any ideas/suggestions.

Steve Estle

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

Re: RFC3280 (and 5280), "Basic Constraints" set to Critical

[Peter Sylvester]

On 08/12/2023 17:36, Phil Smith III wrote:

(Cross-posted to IBM-MAIN and IBMTCP-L)

Our z/OS product acts as a client to our non-z/OS server. As such, it makes TLS 
connections to fetch Policy and keys.

As I've written previously, we had a problem when we added TLSv1.3 support to 
the z/OS product, getting errors:
ERROR check_cert_extensions_3280_and_later(): Basic Constraints extension must 
be critical for CA Certificate


There is a difference between what you must set and what you must verify. 5280/3280 is clear (IMO) 
about that.


when you verify a cert, AND you know about the extension, you just verify the extension and don't 
care about the critical bit


Since the error message seems to indicate that the extension is known, the verifier has no reason to 
checjk the criticality bit.




The fix was to update the root certificate used by the server to add the required 
Critical value for Basic Constraints (henceforth "BC" as a shorthand).


The RFC path validation does not usea selfsignedroot certificate. The only necessary thing for an 
implementation is to have an association between a subject an a public key.


A self signed cert is just handy.




This happened again here this week when a certificate was updated (someone used 
the wrong internal CA, which was old). Once we got it straightened out, I 
started wondering why this only happened once we added TLSv1.3 support. Some 
reading of RFC5280 (which obsoleted 3280) suggests that a PKIX-compliant 
certificate should ALWAYS be rejected if not BC. But this doesn't seem to be 
true until we add the TLSv1.3 support.


what is suggesting this?




I say "seems to" because I don't have an easy way to test all combinations. The 
older version of our z/OS product didn't support TLSv1.3. The changes to implement 1.3 
support added three calls to the stack:

*   One that says "Yeah, we do 1.3":
gsk_attribute_set_enum(pSSI->hEnviron, GSK_PROTOCOL_TLSV1_3, 
GSK_PROTOCOL_TLSV1_3_ON);
*   One to add the 1.3 key shares:
gsk_attribute_set_buffer(pSSI->hEnviron, GSK_CLIENT_TLS_KEY_SHARES, 
"00230024002500290030", 0);
*   One to add the 1.3 ciphers (I think?):
sslStatus = vsgsk_attribute_set_buffer(pSSI->hSocket, GSK_V3_CIPHER_SPECS_EXPANDED, 
"C030C02FC028C027C014130113021303003500380039002F00320033", 0);

There was another change that added SNI support, but that was backported to the 
old version, so I don't think it nets out as a difference between what I had 
available to test. And of course the cert is fixed now, so I couldn't easily 
test more if I wanted to.

SNI is used to identify a server, and in particular, the cert (chain) to be 
presented to the client.


Anyone (Wai? Charles?) have any domain knowledge here? Should gsk be 
categorically rejecting a root certificate that claims to be PKIX-compliant, or 
only if TLSv1.3 is supported?



I'm less interested in getting it fixed if it's wrong, since there's obvious significant 
risk of breaking a lot of existing, working connections-plus as folks move to TLSv1.3 
they'll fix it anyway-than I am in feeling that we can confidently tell customers who hit 
this "Yes, that's a requirement of [TLSv1.3? TLS in general, but IBM only enforces 
it for 1.3? something else?]", and not that it's a peculiarity of our 
implementation. Put another way, the surprise (after reading the RFC and thinking I 
understand it!) is that it breaks when it does-that a non-BC certificate ever works. 
Should it?

Does you product work with TLS 1.2?



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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: Assembler optimization OPTION

[Bernd Oppolzer]

Hi,

there is no such option;
this is not possible, because with ASSEMBLER, the programmer has full 
control about where he or she puts the information elements,
be it static data or code. There is no magic engine like the optimizer 
with compilers which can do anything about that.


This said:

I had a project in 2021 with a large customer which had very old 
ASSEMBLER programs from the 1980s, which had heavy SIIS problems
(store into instruction stream) which had to be resolved. I found out 
that some of them can easily be resolved by the use of clever macros
which separate the static data from the code (by putting them in a 
different CSECT or DSECT). The details are too complicated to discuss here,
but in the end, the changes to the code were minimal. And in the end, we 
achieved our project goals in time and budget.


HTH, kind regards

Bernd


Am 08.12.2023 um 20:29 schrieb Ituriel do Neto:

Hello everyone,

Recently i have seen some discussions related to assembler performance to use 
the L1 cache of the processor better and not mixing instructions and data.

Can you enlighten me which assembler option can be used for this purpose?

Thanks in advance


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer

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