Re: Migrating Loadlibs from PDSE to PDS?

[Support, DUNNIT SYSTEMS LTD.]

Hi Steve,

Just curious: why are you interested in reverting load libraries from PDSE to 
PDS? Thanks.

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

Re: SQA overflow condition

[Peter]

The ESQA usage has gone to 108%.

Is there any tool available in CBTTAPEA which can tell me or trace SQA
users and who are not releasing the storage?

On Mon, Nov 27, 2023, 5:37 PM Allan Staller <
0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:

> Classification: Confidential
>
> 100% concur w/Martin
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Martin Packer
> Sent: Sunday, November 26, 2023 2:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SQA overflow condition
>
> [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.]
>
> (This is not specific advice but a way of thinking about things.)
>
> SQA can, of course, overflow into CSA - with no real harm done. Unless it
> causes CSA to go short. (CSA can't overflow into SQA, of course.)
>
> The above statements are true for both 24-bit and 31-bit.
>
> 1409K below the line, though, is pretty extreme - for 24 bit. If you made
> SQA larger so that it only overflowed, say, by 100K there would be no
> wasted virtual storage.
>
> More importantly, check out the "free CSA" picture. You really don't want
> to run out of that. For 24-bit you want a few hundred K free. (But to
> achieve that might require losing 1MB of 24-bit private, which might not be
> consequence free.)
>
> For 31 bit I like to see at least 100MB free ECSA, preferably more. The
> reason is because ECSA is - in my experience - more volatile.
>
> Speaking of volatility, you need to plan defensively - as a problem can
> lead to surge in SQA and CSA usage .
>
> Final point: I would advocate using SMF 78-2 to build a picture of common
> storage usage - and how variable it is. Here is a blog post I wrote on the
> matter:
>
> htt ps://
> mainframeperformancetopics.com/2020/01/05/how-i-look-at-virtual-storage
>
> (Take out the space to follow the URL - as my mail client turned it into
> an attachment.) 
>
> Cheers, Martin
>
> Sent from my iPad
>
> > On 26 Nov 2023, at 05:40, Peter  wrote:
> >
> > Hello
> >
> > I am able to see the below alert condition under RMF postprocessor III
> >
> >
> >
> > Name Reason Critical val. Possible cause or action
> >
> > *STOR TSQAO > 0 1409K bytes SQA overflow into CSA 1409K.
> >
> >
> >
> >
> >
> > Our SQA and CSA set up in our IEASYSxx is as below
> >
> >
> >
> > CSA=(2000,30)
> >
> >
> >
> > SQA=(16,192)
> >
> >
> > Hardware: z14
> > LPAR : 16gb memory
> > zOS 2.4
> >
> > Do I have think about tunning the SQA parameter ?
> >
> > Regards
> > Peter
> >
> > --
> > 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
> ::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
>

--
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 12/10/2023 9:05 AM, Ed Jaffe wrote:
Let me see see if I can make these object decks and repackage the 
latest FLOWASM for VSE and VM environments in the flowasm.zip file for 
you. If I have trouble doing so, maybe you will help me?


Turns out the last packaging of FLOWASM.ZIP was in 2009. There is now a 
new one here:


https://phoenixsoftware.com/ftp/demo/flowasm.zip (Ver 2, Rel 2)

Sadly, I no longer have the HLASM Toolkit in my VSE environment. So I 
compiled it under z/OS faking out the  SETC symbol (initially derived 
from _ID) to be "NOT z/OS" which caused it to skip over the 
z/OS-only code.


The object deck it produced should link on VSE (and CMS). If not, the 
latest source should compile okay if you have the HLASM Toolkit available.


Let me know how it works out...


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

[Seymour J Metz]

I'm talking about very old values of "new"; I've seen code that doesn't use 
anything beyond S/370. 

I cane see not using the Telum instructions, and even not using the SIMD 
instructions, but anything older than that?

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


From: IBM Mainframe Discussion List  on behalf of 
Leonard D Woren 
Sent: Sunday, December 10, 2023 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler optimization OPTION

Seymour J Metz wrote on 12/10/2023 7:06 AM:
> Why does it take so long for people to use new features? HLASM has a lot of 
> nifty things that have been around and well documented for decades.

Right.  I actually found at least one very old bug by using HLA option
FLAG(PAGE0).  An annoyance though is that there are some IBM macros
which get flagged, so you have to either temporarily turn off
FLAG(PAGE0) around them, or in some case, simply insert USING PSA,0.

> A similar question exists for new instructions; how many shops are still 
> running boxen that don't support the z immediate, long displacement and 
> relative instructions, e,g.,JC, LARL, LAY?

Which value of "new" are you using?  Our products are supported on all
z/OS releases still supported by IBM, so I'm somewhat limited in what
instruction set I can use.  Currently, z/OS 2.4 is still supported (I
assume until 2024-09-30), and since z/OS 2.4 runs on z12, I can't go
past ZS(6) instructions.  However, that turns out to be a LOT of nifty
instructions.  I have eliminated nearly all 2 and 4 byte literals,
among other improvements.

With the relative branch instructions and SYSSTATE ARCHLVL=2, there is
no excuse for base registers for code.

Note that LARL was retrofitted back to S/390 hardware, so there is no
excuse whatsoever for not using it.

I have a loop somewhere using about 20 registers.  Have fun with that.

/Leonard

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


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

[Leonard D Woren]

Seymour J Metz wrote on 12/10/2023 7:06 AM:

Why does it take so long for people to use new features? HLASM has a lot of 
nifty things that have been around and well documented for decades.


Right.  I actually found at least one very old bug by using HLA option 
FLAG(PAGE0).  An annoyance though is that there are some IBM macros 
which get flagged, so you have to either temporarily turn off 
FLAG(PAGE0) around them, or in some case, simply insert USING PSA,0.



A similar question exists for new instructions; how many shops are still 
running boxen that don't support the z immediate, long displacement and 
relative instructions, e,g.,JC, LARL, LAY?


Which value of "new" are you using?  Our products are supported on all 
z/OS releases still supported by IBM, so I'm somewhat limited in what 
instruction set I can use.  Currently, z/OS 2.4 is still supported (I 
assume until 2024-09-30), and since z/OS 2.4 runs on z12, I can't go 
past ZS(6) instructions.  However, that turns out to be a LOT of nifty 
instructions.  I have eliminated nearly all 2 and 4 byte literals, 
among other improvements.


With the relative branch instructions and SYSSTATE ARCHLVL=2, there is 
no excuse for base registers for code.


Note that LARL was retrofitted back to S/390 hardware, so there is no 
excuse whatsoever for not using it.


I have a loop somewhere using about 20 registers.  Have fun with that.

/Leonard


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

[Paul Gilmartin]

On Sun, 10 Dec 2023 10:19:15 -0600, Mike Schwab wrote:

>https://github.com/dmolony/Xmit
>Mac, Linux, Windows.
>
Thanks.  I go there.  It's easy enough to download XmitApp.jar.  But I see:
Installation
Download and install Java 17 and JavaFX 17, which are now separate 
downloads.
Download XmitApp.
Create executable run file.

I think I have the Java I need.  I've used it. But "JavaFX 17"?  Looking around 
at:
,
I read:  Installing the JavaFX SDK on Windows or Mac
Download the latest JavaFX SDK installer file for Windows (an EXE 
extension) or Mac OS X (a DMG extension).

There seems to be a link in there, but no .dmg file.
I believe they threw it over the wall to FOSS.

--  
gil

--
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 12/10/2023 2:08 AM, Martin Trübner wrote:

Ed,

I have FLOWASM running here in z/VSE, but can not find the ASMA435 
error-message.


I am sure it affects VSE users as well and hence will prepare a VSE 
version and publish it the usual way (or did I send a VSE version to 
you?*)


What do I need out of the XMI package to prepare the VSE version?


flowasm.zip in the same directory has the stuff for VSE. I have not 
updated that yet with the latest code. It looks to be last updated in 2003:


 Directory of C:\Users\Ed Jaffe\Downloads\flowasm\flowasm

12/10/2023  08:55 AM      .
12/10/2023  08:55 AM      ..
12/10/2023  08:55 AM 1,520 ASMFLOW
12/10/2023  08:55 AM 7,280 EEJASM1
12/10/2023  08:55 AM 7,280 EEJASM2
12/10/2023  08:55 AM 4,160 EEJASM3
12/10/2023  08:55 AM   135,040 FLOWASM
12/10/2023  08:55 AM 7,680 OBJCMS
12/10/2023  08:55 AM 7,760 OBJVSE
12/10/2023  08:55 AM   165 readme.txt
12/10/2023  08:55 AM    13,200 SAMPLE
12/10/2023  08:55 AM    42,000 STKSAVE
  10 File(s)    226,085 bytes
   2 Dir(s)  241,390,202,880 bytes free

Those OBJCMS and OBJVSE entries are obviously the object decks for those 
environments, but I can't remember why they were necessary. Perhaps 
because I didn't provide JCL or VM EXEC to produce them? Haha! At my age 
I've forgotten more than I know! LOL


Let me see see if I can make these object decks and repackage the latest 
FLOWASM for VSE and VM environments in the flowasm.zip file for you. If 
I have trouble doing so, maybe you will help me?


Thanks,


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

I guess some sort of answer is:

if you have programs from - say - the 1980s and you have no reason for 
changing them - and no business case -
then you probably don't want to change them as long as they run 
satisfactorily.


Nowadays it is even trickier ... sometimes I come along some programs 
which from my technical point of view
need some maintenance, but the bean counters tell me that I am not 
allowed to do it as long as nobody is writing
a ticket for them ... and if I write a ticket myself, it has to go thru 
a lot of quality gate checks before I am allowed to
start working on it, mostly done by people, who don't know nothing about 
the technical facts ...

this can take weeks and months, and in the end, it may well be refused :-(

It seems to be easier for the top management to complain about the 
mainframe being "old and clumsy"
and then trying to replace it by what they consider "modern technology" 
... but then I see these migration projects
always failing, which keeps the mainframe running and running and the 
mainframe specialists growing older and older.


I'm 64 now, which is young, IMO.  My colleagues (still working, for the 
same customers) are 73, for example.


Kind regards

Bernd



Am 10.12.2023 um 16:06 schrieb Seymour J Metz:

Why does it take so long for people to use new features? HLASM has a lot of 
nifty things that have been around and well documented for decades.

A similar question exists for new instructions; how many shops are still 
running boxen that don't support the z immediate, long displacement and 
relative instructions, e,g.,JC, LARL, LAY?

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


From: IBM Mainframe Discussion List  on behalf of Peter 
Relson 
Sent: Sunday, December 10, 2023 9:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler optimization OPTION

The starting point to almost all of these discussions tends to be to write 
reentrant programs (as high level languages naturally produce).

If you must stick with a non-reentrant program, consider the LOCTR directive. If you don't feel like truly moving the 
data-defining statements within your program, you can use the LOCTR directive to help to "move" data to a 
separate area. You might have an area for your "code" and an area for your "static data" and an 
area for your "dynamic data"

Peter Relson
z/OS Core Technology Design


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


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

[Mike Schwab]

https://github.com/dmolony/Xmit
Mac, Linux, Windows.

On Sun, Dec 10, 2023 at 9:41 AM Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 10 Dec 2023 08:24:47 -0600, Mike Schwab wrote:
>
> >Xmit Manager.  https://www.cbttape.org/njw/
> >
> Is there a Windows-free alternative?
>
>
> >> What do I need out of the XMI package to prepare the VSE version?
>
> --
> gil
>
> --
> 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: RFC3280 (and 5280), "Basic Constraints" set to Critical

[Phil Smith III]

Charles Mills wrote, in part:
>Confirming:

>The complaint was at the client end. The client is z/OS. The complaint
>was that the CA root had a Basic Constraints extension that was not
>marked as critical?

Yes. And that it only seems to matter to gsk when the client says "I can do 
TLSv1.3".

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

[Paul Gilmartin]

On Sat, 9 Dec 2023 16:20:18 -0800, Ed Jaffe wrote:
>...
>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).
>
How does it deal with macro libraries?  I imagine an extreme case is a
SYSLIB concatenation of a UNIX directory and SYS1.MACLIB.

-- 
gil

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

[Paul Gilmartin]

On Sun, 10 Dec 2023 08:24:47 -0600, Mike Schwab wrote:

>Xmit Manager.  https://www.cbttape.org/njw/
>
Is there a Windows-free alternative?


>> What do I need out of the XMI package to prepare the VSE version?

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

[Seymour J Metz]

Is REVIEW currently packaged with PDS86 in CBTTAPE file 182.

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


From: IBM Mainframe Discussion List  on behalf of 
Peter Vels 
Sent: Saturday, December 9, 2023 9:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Migrating Loadlibs from PDSE to PDS?

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

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

[Lennie Dymoke-Bradshaw]

It's a fair question. I think for me it is because I rarely write a brand new 
program. I take something that works and then change it to do what I want. 
Often I find I can easily do what I need without using newer instructions.

Lennie Dymoke-Bradshaw
https: //rsclweb.com
-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: 10 December 2023 15:07
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler optimization OPTION

Why does it take so long for people to use new features? HLASM has a lot of 
nifty things that have been around and well documented for decades.

A similar question exists for new instructions; how many shops are still 
running boxen that don't support the z immediate, long displacement and 
relative instructions, e,g.,JC, LARL, LAY?

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


From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Sunday, December 10, 2023 9:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler optimization OPTION

The starting point to almost all of these discussions tends to be to write 
reentrant programs (as high level languages naturally produce).

If you must stick with a non-reentrant program, consider the LOCTR directive. 
If you don't feel like truly moving the data-defining statements within your 
program, you can use the LOCTR directive to help to "move" data to a separate 
area. You might have an area for your "code" and an area for your "static data" 
and an area for your "dynamic data"

Peter Relson
z/OS Core Technology Design


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


--
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: Assembler optimization OPTION

[Seymour J Metz]

Why does it take so long for people to use new features? HLASM has a lot of 
nifty things that have been around and well documented for decades.

A similar question exists for new instructions; how many shops are still 
running boxen that don't support the z immediate, long displacement and 
relative instructions, e,g.,JC, LARL, LAY?

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


From: IBM Mainframe Discussion List  on behalf of 
Peter Relson 
Sent: Sunday, December 10, 2023 9:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Assembler optimization OPTION

The starting point to almost all of these discussions tends to be to write 
reentrant programs (as high level languages naturally produce).

If you must stick with a non-reentrant program, consider the LOCTR directive. 
If you don't feel like truly moving the data-defining statements within your 
program, you can use the LOCTR directive to help to "move" data to a separate 
area. You might have an area for your "code" and an area for your "static data" 
and an area for your "dynamic data"

Peter Relson
z/OS Core Technology Design


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


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

[Mike Schwab]

Xmit Manager.  https://www.cbttape.org/njw/

On Sun, Dec 10, 2023 at 4:08 AM Martin Trübner <
047eec287bd9-dmarc-requ...@listserv.ua.edu> wrote:

> Ed,
>
>
> I have FLOWASM running here in z/VSE, but can not find the ASMA435
> error-message.
>
>
> I am sure it affects VSE users as well and hence will prepare a VSE
> version and publish it the usual way (or did I send a VSE version to you?*)
>
>
> What do I need out of the XMI package to prepare the VSE version?
>
>
> could you send me that, since I do not have a running z/OS system in
> reach anymore ?
>
>
> ASCII or EBDIC is not the problem- but XMI is.
>
>
> Martin
>
> (*) after all, it was Jan 2009 when I did this and a lot has changed. I
> may have offered it on my webpage- but I realy do not recall- however I
> have all the files from back then here. So If you believe, there is no
> point in creating a VSE version from this- say so. As long as there is
> no request for it there is no point in doing it at all.
>
>
> --
> 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

[Peter Relson]

The starting point to almost all of these discussions tends to be to write 
reentrant programs (as high level languages naturally produce).

If you must stick with a non-reentrant program, consider the LOCTR directive. 
If you don't feel like truly moving the data-defining statements within your 
program, you can use the LOCTR directive to help to "move" data to a separate 
area. You might have an area for your "code" and an area for your "static data" 
and an area for your "dynamic data"

Peter Relson
z/OS Core Technology Design


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

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

[Peter Sylvester]

Ok.

RFC 5820 is clear (not necessarily cristal clear) but anyway:

1: Read the introduction about extensions. In short and by doing some boolean 
logic manip:

If you know how to treat an extension, the criticality bit is irrelevant for 
the verification.
Since the implementation in question knows about BC, it should never ever look at the critbit in 
*ANY* cert. It just looks whether it is a CA, and if path length is ok.


2: The verification algorithm is outlined in detail. Look at the input. It is basically a public 
key+algo + an identity. Not a cert. No extensions, etc.


One  should be able to use X509 version 1 cert as a container for the root 
pubkey.

On 10/12/2023 04:17, Phil Smith III wrote:

Peter Sylvester wrote, in part:


T
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
  
You wrote that there is a suggesting to reject non-pkix conformant certs. Where is that? Not in the 
path verification.

Does you product work with TLS 1.2?
  


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

  

Good.


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 think you should ask IBM about this change in behaviour.

I have not followed the CA forum btw. I prefer to go to the beach (200m)  or 
the alpes (25km) :-)

best

Peter


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

[Martin Trübner]

Ed,


I have FLOWASM running here in z/VSE, but can not find the ASMA435 
error-message.



I am sure it affects VSE users as well and hence will prepare a VSE 
version and publish it the usual way (or did I send a VSE version to you?*)



What do I need out of the XMI package to prepare the VSE version?


could you send me that, since I do not have a running z/OS system in 
reach anymore ?



ASCII or EBDIC is not the problem- but XMI is.


Martin

(*) after all, it was Jan 2009 when I did this and a lot has changed. I 
may have offered it on my webpage- but I realy do not recall- however I 
have all the files from back then here. So If you believe, there is no 
point in creating a VSE version from this- say so. As long as there is 
no request for it there is no point in doing it at 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?

[Martin Trübner]

even bugs!!!

Am 09.12.23 um 16:52 schrieb Ed Jaffe:

They never improve anything without an RFE asking for it. [sigh]



Martin

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