Re: JES3 system STC gets wrong Symbol replacements

[Attila Fogarasi]

For instream symbol substitution there is an option for symbols to be
processed on either the conversion system or the execution system (via the
SYMBOLS= parm).  Sounds like your client is converting on system A and
executing on system B with SYMBOLS=CNVTSYS option.  Or some variant of
that.

On Fri, May 12, 2023 at 12:15 PM Mark Charles 
wrote:

> Client has 3 systems in JES3 Sysplex.  System A is z/OS 2.3 JES3 Global.
> System B is z/OS 2.5 JES3 Local with no CIs defined.  Other system not
> important.
>
> When starting STC with system symbols on System B, the symbols are
> "replaced" by information from System A.  Is this normal?  Is there a way
> to get the symbols "replaced" with information from the Local System B?
>
> --
> 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

JES3 system STC gets wrong Symbol replacements

[Mark Charles]

Client has 3 systems in JES3 Sysplex.  System A is z/OS 2.3 JES3 Global. System 
B is z/OS 2.5 JES3 Local with no CIs defined.  Other system not important.

When starting STC with system symbols on System B, the symbols are "replaced" 
by information from System A.  Is this normal?  Is there a way to get the 
symbols "replaced" with information from the Local System B?

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

Re: IBM VTS category definition

[Attila Fogarasi]

Pretty good explanation in this white paper,
https://www.ibm.com/support/pages/system/files/inline-files/White_Paper_-_TS7700_Best_Practices_-_Return-To-Scratch_Considerations_for_DR_Testing_V12.pdf

On Fri, May 12, 2023 at 12:24 AM Radoslaw Skorupka <
0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:

> I just RTFM, but I'm not sure about scratch category definition in VTS
> TS7700.
> I mean Expire Hold Settings and Expire Hold checkbox.
>
> My understanding:
> No expiration - scratch will *never* be reused.  ...or maybe it means
> the scratch is available for reuse immediately after transition from
> private to scratch?
>
> Expire Hold, let's say 48h. That means the scratch will be available two
> days after the transition from private to scratch.
> Q: What is the meaning of Expire Hold checkbox?
>
>
>
>
> Regards
> --
> 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
>

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

Re: IBM VTS category definition

[Nobuhiko Furuya]

Hi,

"Expire time" in TS7700 scratch category means when TS7700 deletes the 
scratched volume file on the TVC after the volume's category was changed 
from private to scratch. Before the scratched volume file on the TVC is 
deleted, you can reuse the volume data by changing the volume attribute 
from scratch to private.
But "Expire Time" is based on the best effort. If all scratch volumes 
which exceed expire time are exhausted, scratch volumes which don't 
exceed expire time will be selected as scratch volume. In this 
situation, you can't reuse the volume data before overwritten.
So if you want to ensure that scratch volumes which don't exceed expire 
time are not selected for scratch volume, you need to check "Expire Hold".


Best regards,

Nobuhiko Furuya(古谷信彦)
V-SOL Inc.

On 2023/05/11 23:24, Radoslaw Skorupka wrote:
I just RTFM, but I'm not sure about scratch category definition in VTS 
TS7700.

I mean Expire Hold Settings and Expire Hold checkbox.

My understanding:
No expiration - scratch will *never* be reused.  ...or maybe it means 
the scratch is available for reuse immediately after transition from 
private to scratch?


Expire Hold, let's say 48h. That means the scratch will be available 
two days after the transition from private to scratch.

Q: What is the meaning of Expire Hold checkbox?




Regards


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

Re: WLM for z/OSMF

[Attila Fogarasi]

Discretionary probably is ok, remember that SVR1 is the server address
space which is just WAS and competes with other application regions like
CICS AOR and IMS regions.  ANG1 provides services to SVR1 for the
"application" being run in z/OSMF.  How to manage resource consumption and
priority is no different than for the other lpar workload, though the
customer base for z/OSMF being sysprogs may view it is much higher priority
:)  It's only the Angel task that is time critical, hence defaulting to
SYSSTC.

On Fri, May 12, 2023 at 6:09 AM Colin Paice  wrote:

> I was asked
>
> We are setting up z/OSMF for the 1st time (can't really avoid it any
> longer). I've noticed that the IZUANG1 task has a default WLM SC of SYSSTC
> (which is probably OK), but the IZUSVR1 task has a default of Discretionary
> - which is probably NOT OK. Do you have a recommendation for a functional
> SC that won't eat the LPAR alive?
>
> Does anyone have a recommendation for this?
>
> Colin
>
> --
> 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: ispf , way to achieve the last ispf msgid from rexx

[Seymour J Metz]

This is killing a fly with a sledge hammer, but maybe Exit 15: DISPLAY service 
exit?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Weizman arbel [wwar...@gmail.com]
Sent: Thursday, May 11, 2023 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ispf , way to achieve the last ispf msgid from rexx

>Have you looked at ZERRMSG, ZERRSM, and ZERRL?
It takes an effect when there is an error/message
And it doesn't return
the last MSGID.
MSGID Includes the last message code (code-id)
for example: after save command Inside edit dataset the message is  "Data set 
saved"   the msgid="ISRE017 "
I would like the message code "ISRE017 "




On Thu, 11 May 2023 10:10:18 +, Seymour J Metz  wrote:

>Have you looked at ZERRMSG, ZERRSM, and ZERRL?
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Weizman arbel [wwar...@gmail.com]
>Sent: Thursday, May 11, 2023 1:23 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: ispf , way to achieve the last ispf msgid from rexx
>
>Hello  ,
>
>from rexx
>Which command / way to achieve the last ispf msgid
>
>example:
>The result of the command  msgid
>' The message ID of the last message was "ISRE017 " '
>
>I would like to achieve the  "ISRE017"
>from rexx
>
>
>thanks,
>   weizman
>
>--
>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: Logical Nor (¬) in ASCII-based code pages?

[Rick Troth]

Agreed.
I took a short-cut in so far as the high bit is '1'.
But I gotta own that, you are correct, 'AC'x is *not* a proper 
extender/introducer in UTF-8.


-- R; <><


On 5/11/23 15:56, Seymour J Metz wrote:

'AC'X is not valid as the first octet of a UTF-8 sequence and the indicator is 
in the first octet, which must be one of

 0xxx
 110x
 1110
 0xxx

'AC'X is valid in the second, third or fourth octet.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rick Troth [tro...@gmail.com]
Sent: Thursday, May 11, 2023 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logical Nor (¬) in ASCII-based code pages?

On 5/8/23 14:48, Phil Smith III wrote:

Seymour J Metz wrote, in part:

You seem to be confirming what I wrote; if the locale is UTF-8 then
your character data should be UTF-8. The ¬ character in UTF-8 has a
different encoding from the ¬ character in Unicode, so there is no
issue of a zero octet. '00AC'X is not a valid UTF-8 string.

There is no “encoding” “in Unicode”. That’s the point, and is why you can’t say 
“AC” and expect it to be meaningful. Folks might guess, but (especially with 
endianness) might get it wrong.

‘00ac’x is indeed invalid as a UTF-8 encoded value, but it’s not the 00 that’s 
bad (that’s fine, it’s a null): it’s the AC, which is invalid because the top 
two bits are 10 and that means it’s a continuation byte. So a UTF-8 parser 
chugs along, sees the 00 and says “OK, good, that’s a single-byte encoding of a 
null”. But then it looks at the AC and says “Hey, this is supposed to be a 
continuation, and I’m not IN a multi-byte encoded character, that’s no good”. 
(One of the cool things about UTF-8 is that, assuming proper UTF-8, you can 
start in the middle of a string and, if you find you’re at a continuation byte, 
you can back up to the first byte in the tuple and start from there!)

The above assumes big-endian, of course.

I’m’a keep harping on “Unicode is not an encoding” because it isn’t and it 
matters. Former manager beat that into my head, and it took a while for me to 
get it, so if you’ve bothered to read this far and feel like it’s an artificial 
distinction, I dig. It’s not.


Phil's right. Unicode is not an encoding.
UFT-8 is an encoding of Unicode which fits nicely in many historically
8-bit spaces. UTF-8 allows the Ukrainians to use Cyrillic (one of many
character sets in Unicode) in their web pages without having to play
musical code pages.

If any given system is trying to process a UTF-8 stream and comes across
00AC (at end of input, THAT'S IMPORTANT), it will treat the 00 as NULL
and move along, then will fail on AC and either 1) throw an error, 2)
try to cope (treating it as ISO-8859-1, maybe), or 3) ignore that byte.
In no case can a UTF-8 processor "do the right thing" with just AC.

In sequence, AC is one of many continuation indicators. The UTF-8
processor expects more. If it finds more, it WON'T interpret that as
logical not. If it doesn't find more, then see previous paragraph.




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


-- R; <><

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

WLM for z/OSMF

[Colin Paice]

I was asked

We are setting up z/OSMF for the 1st time (can't really avoid it any
longer). I've noticed that the IZUANG1 task has a default WLM SC of SYSSTC
(which is probably OK), but the IZUSVR1 task has a default of Discretionary
- which is probably NOT OK. Do you have a recommendation for a functional
SC that won't eat the LPAR alive?

Does anyone have a recommendation for this?

Colin

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

Re: Logical Nor (¬) in ASCII-based code pages?

[Seymour J Metz]

Wrong for ISO-8859-15, but not wrong for CP437 and CP850.

Latin-1 doesn't have the € (Euro); I'd go with Latin-9, although I believe that 
W3C blessed Latin-1.

IETF has blessed UTF-8 as the way forward.

I wasn't asking which encoding was best (IMHO, it's 'C2AC'X, THE UTF-8  
transform of 'AC'X), but rather what various current interpreters expect.

I believe that NetRexx supports a UTF-8 encoding of the source, but I was 
concerned with classic and OO flavors.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rick Troth [tro...@gmail.com]
Sent: Thursday, May 11, 2023 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logical Nor (¬) in ASCII-based code pages?

Unicode is the way to go in this case. In that space, logical not is
"U+00AC", so the AA you're seeing is wrong.

In the 8-bit days (prior to Unicode), I would recommend ISO 8859-1 (so
called "Western Latin 1"). There too, logical not is 0xAC.

Does this help?

-- R; <><


On 5/7/23 09:27, Seymour J Metz wrote:
> I've seen Logical Not (¬) at AA and at AC. Are there and ASCII-based code 
> pages that have it at a third position? Put another way, is there a third 
> code point that ooRexx and Regina should recognize as ¬?
>
>
>
> --
> 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

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

Re: Logical Nor (¬) in ASCII-based code pages?

[Seymour J Metz]

'AC'X is not valid as the first octet of a UTF-8 sequence and the indicator is 
in the first octet, which must be one of 

0xxx
110x
1110
0xxx

'AC'X is valid in the second, third or fourth octet.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rick Troth [tro...@gmail.com]
Sent: Thursday, May 11, 2023 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Logical Nor (¬) in ASCII-based code pages?

On 5/8/23 14:48, Phil Smith III wrote:
> Seymour J Metz wrote, in part:
>> You seem to be confirming what I wrote; if the locale is UTF-8 then
>> your character data should be UTF-8. The ¬ character in UTF-8 has a
>> different encoding from the ¬ character in Unicode, so there is no
>> issue of a zero octet. '00AC'X is not a valid UTF-8 string.
> There is no “encoding” “in Unicode”. That’s the point, and is why you can’t 
> say “AC” and expect it to be meaningful. Folks might guess, but (especially 
> with endianness) might get it wrong.
>
> ‘00ac’x is indeed invalid as a UTF-8 encoded value, but it’s not the 00 
> that’s bad (that’s fine, it’s a null): it’s the AC, which is invalid because 
> the top two bits are 10 and that means it’s a continuation byte. So a UTF-8 
> parser chugs along, sees the 00 and says “OK, good, that’s a single-byte 
> encoding of a null”. But then it looks at the AC and says “Hey, this is 
> supposed to be a continuation, and I’m not IN a multi-byte encoded character, 
> that’s no good”. (One of the cool things about UTF-8 is that, assuming proper 
> UTF-8, you can start in the middle of a string and, if you find you’re at a 
> continuation byte, you can back up to the first byte in the tuple and start 
> from there!)
>
> The above assumes big-endian, of course.
>
> I’m’a keep harping on “Unicode is not an encoding” because it isn’t and it 
> matters. Former manager beat that into my head, and it took a while for me to 
> get it, so if you’ve bothered to read this far and feel like it’s an 
> artificial distinction, I dig. It’s not.


Phil's right. Unicode is not an encoding.
UFT-8 is an encoding of Unicode which fits nicely in many historically
8-bit spaces. UTF-8 allows the Ukrainians to use Cyrillic (one of many
character sets in Unicode) in their web pages without having to play
musical code pages.

If any given system is trying to process a UTF-8 stream and comes across
00AC (at end of input, THAT'S IMPORTANT), it will treat the 00 as NULL
and move along, then will fail on AC and either 1) throw an error, 2)
try to cope (treating it as ISO-8859-1, maybe), or 3) ignore that byte.
In no case can a UTF-8 processor "do the right thing" with just AC.

In sequence, AC is one of many continuation indicators. The UTF-8
processor expects more. If it finds more, it WON'T interpret that as
logical not. If it doesn't find more, then see previous paragraph.



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


-- R; <><

--
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: Unlike data sets concatenation - revised 4

[Michael Stein]

On Thu, May 11, 2023 at 12:50:12PM -0500, Pierre Fichaud wrote:
> I'm back onto this problem.
> I wrote a proof-of-concept program and it works.
> I've modified an existing z/OS product and my changes don't work.

This is the first we've heard that all the related code wasn't
yours (or part of z/OS open/close/eov).

Do you have the source to the product with the failing case?

I'm guessing NO, as this would be easy to search the source for
modifications to DCB fields.

Are you providing the DCB to the product and the product 
modifies it?  Who issues the open you or the product?

It's clear now that the product is modifying the DCB before the open.

Anyway, however you got your dumps of the DCB before the open you could
instead at that point in execution zero out the DCB LRECL and BLKSIZE
fields, then let the open proceed.

This might not take having the source to the product.

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

Re: Unlike data sets concatenation - revised 4

[Seymour J Metz]

A little hard to read without field names or at least offsets for each 
doubleword, but DCBOFLGS is a bit puzzling; I would have expected 08 and 18 
where I see 0A and 1A. Could you post the code that works and the code that 
does not work?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Pierre Fichaud [pr...@videotron.ca]
Sent: Thursday, May 11, 2023 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Unlike data sets concatenation - revised 4

I'm back onto this problem.
I wrote a proof-of-concept program and it works.
I've modified an existing z/OS product and my changes don't work.

Only DSNAME and DISP are coded on the DD statements.

1st file is VB with LRECL=200
2nd file is VB with LRECL=230
3rd file is FB with LRECL=1000.

Proof-of concept :

It is AMODE 31, RMODE ANY and re-entrant.
It's save area/working storage is in 31-bit storage.

DCB before OPEN
09.18.12 JOB13853  +6EB0       
0001 4000 0001
09.18.12 JOB13853  +6ED0 6F3A  C9D5D7E4 E3404040  0A004800 
0001 0001 
09.18.12 JOB13853  +6EF0  0001 0001 0001   
0001  0001

DCB after OPEN
09.18.12 JOB13853  +6EB0   01D0 00F43026  002FE5A2 
05007C70 4000 6CB8
09.18.12 JOB13853  +6ED0 02006F3A 50006F10 00404800 008C5D84  1AE30E68 
00CA99F8 0A01 020903E8
09.18.12 JOB13853  +6EF0 30013030 6D28    00C8 
  80E37A58

DCB inside of OPEN exit prior to a reread (GET)
09.18.12 JOB13853  +6EB0   01D1 00F43026  002FE5A2 
05007978 4000 6CB8
09.18.12 JOB13853  +6ED0 02006F3A 50006F10 00544800 008C508C  1AE30E68 
00CA99F8 0A01 0209047E
09.18.12 JOB13853  +6EF0 30013030 6D28    00E6 
  80E37A58

DCB inside of OPEN exit prior to a reread (GET)
09.18.12 JOB13853  +6EB0   01D5 00F43026  002FE5A2 
050070A0 4000 6CB8
09.18.12 JOB13853  +6ED0 02006F3A 90006F10 00684800 008C6894  1ACAC000 
00CA99F8 0A01 02096978
09.18.12 JOB13853  +6EF0 30013030 6D28    03E8 
  80E37A58

ISV product :

The program that doesn't work is not re-entrant and runs in AMODE 31 but is 
RMODE 24.
Its save area/working storage is in 24-bit storage.

One can see that the DCB prior to the reread does not have the attributes of 
the 2nd dataset namely LRECL=230 and BLKSIZE=1150.

 DCB before OPEN
 000110180       0001 
4000 0001  *... ..  *
 00011038  20  00012580  C6C9D3C5 C1404040 0A004800 0001 
0001 03E8  *.   FILEA.  ... .. Y*
 00011058  40   0001 0001 0001 00C8 0001 
 0001  *... ... ... ...H... ... *

 DCB  after OPEN
 000110180    01D0 00F43026 002FE5A2 05028C70 
4000 000252D0  * }...4  . Vs.. ..  }*
 00011038  20  02012580 500112D0 00A44800 008C4064 1AE30E68 00CA99F8 
0A01 020903E8  *&  }.u ..T  . r8 ..Y*
 00011058  40  30013030 00025340   00C8  
 80E37A58  *.   ...H T: *

 DCB inside of OPEN exit prior to a reread (GET)
 000110180    01D1 00F43026   002FE5A2 05028C70 
4000 000252D0  * J...4  . Vs.. ..  }*
 00011038  20  02012580 500112D0 00B84800 008C5A6C 1AE30E68 00CA99F8 
0A01 020903E8  *&  }.  .. !% T  . r8 ..Y*
 00011058  40  30013030 00025340      00C8  
 80E37A58  *.   ...H T: *

I see the SVC   37 entry in the system trace table but no corresponding 
SVCR   37.
Then abend S001-4.

  CPU STATUS:
  BLS18058I Warnings regarding STRUCTURE(Psa) at ASID(X'0001') 00:
  BLS18300IStorage not in dump
  PSW=07541000   00DAB422
  (Running in PRIMARY, key 5, AMODE 24, DAT ON, SUPERVISOR STATE)
  Disabled for PER
 ASID(X'001A') DAB422. IGC0005E+1422 IN PLPA
ASCB26 at FB5D00, JOB(TH127153), for the home ASID
ASXB26 at 8FD000 and TCB26E at 8D2AA0 for the home ASID
HOME ASID: 001A PRIMARY ASID: 001A SECONDARY ASID: 001A

General purpose register values
  Left halves of all registers contain zeros
 0-3  8400  84001000  008C40EB  00DAB438
 4-7  008C4420  008C4474  008C4428  008C40B0
8-11 008FF708  008CA088  00F4DF78  008C5A6C
  12-15 008C45E4  00027988  80DAB328  0004

Access register values
  0-3  008FB37C      
  4-7        
 8-11       
   12-15       

Old sites

[W Mainframe]

Hi
Looking for people who is running VM/ESA in production. If yes, can we share 
some ideas?
ThanksDan

Sent from Yahoo Mail for iPhone

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

Unlike data sets concatenation - revised 4

[Pierre Fichaud]

I'm back onto this problem.
I wrote a proof-of-concept program and it works.
I've modified an existing z/OS product and my changes don't work.

Only DSNAME and DISP are coded on the DD statements.

1st file is VB with LRECL=200
2nd file is VB with LRECL=230
3rd file is FB with LRECL=1000.

Proof-of concept :

It is AMODE 31, RMODE ANY and re-entrant.
It's save area/working storage is in 31-bit storage.

DCB before OPEN
09.18.12 JOB13853  +6EB0       
0001 4000 0001
09.18.12 JOB13853  +6ED0 6F3A  C9D5D7E4 E3404040  0A004800 
0001 0001 
09.18.12 JOB13853  +6EF0  0001 0001 0001   
0001  0001

DCB after OPEN
09.18.12 JOB13853  +6EB0   01D0 00F43026  002FE5A2 
05007C70 4000 6CB8
09.18.12 JOB13853  +6ED0 02006F3A 50006F10 00404800 008C5D84  1AE30E68 
00CA99F8 0A01 020903E8
09.18.12 JOB13853  +6EF0 30013030 6D28    00C8 
  80E37A58

DCB inside of OPEN exit prior to a reread (GET)
09.18.12 JOB13853  +6EB0   01D1 00F43026  002FE5A2 
05007978 4000 6CB8
09.18.12 JOB13853  +6ED0 02006F3A 50006F10 00544800 008C508C  1AE30E68 
00CA99F8 0A01 0209047E
09.18.12 JOB13853  +6EF0 30013030 6D28    00E6 
  80E37A58

DCB inside of OPEN exit prior to a reread (GET)
09.18.12 JOB13853  +6EB0   01D5 00F43026  002FE5A2 
050070A0 4000 6CB8
09.18.12 JOB13853  +6ED0 02006F3A 90006F10 00684800 008C6894  1ACAC000 
00CA99F8 0A01 02096978
09.18.12 JOB13853  +6EF0 30013030 6D28    03E8 
  80E37A58

ISV product :

The program that doesn't work is not re-entrant and runs in AMODE 31 but is 
RMODE 24.
Its save area/working storage is in 24-bit storage.

One can see that the DCB prior to the reread does not have the attributes of 
the 2nd dataset namely LRECL=230 and BLKSIZE=1150.

 DCB before OPEN
 000110180       0001 
4000 0001  *... ..  *
 00011038  20  00012580  C6C9D3C5 C1404040 0A004800 0001 
0001 03E8  *.   FILEA.  ... .. Y*
 00011058  40   0001 0001 0001 00C8 0001 
 0001  *... ... ... ...H... ... *

 DCB  after OPEN
 000110180    01D0 00F43026 002FE5A2 05028C70 
4000 000252D0  * }...4  . Vs.. ..  }*
 00011038  20  02012580 500112D0 00A44800 008C4064 1AE30E68 00CA99F8 
0A01 020903E8  *&  }.u ..T  . r8 ..Y*
 00011058  40  30013030 00025340   00C8  
 80E37A58  *.   ...H T: *

 DCB inside of OPEN exit prior to a reread (GET)
 000110180    01D1 00F43026   002FE5A2 05028C70 
4000 000252D0  * J...4  . Vs.. ..  }*
 00011038  20  02012580 500112D0 00B84800 008C5A6C 1AE30E68 00CA99F8 
0A01 020903E8  *&  }.  .. !% T  . r8 ..Y*
 00011058  40  30013030 00025340      00C8  
 80E37A58  *.   ...H T: *

I see the SVC   37 entry in the system trace table but no corresponding 
SVCR   37.
Then abend S001-4.

  CPU STATUS:
  BLS18058I Warnings regarding STRUCTURE(Psa) at ASID(X'0001') 00:
  BLS18300IStorage not in dump
  PSW=07541000   00DAB422
  (Running in PRIMARY, key 5, AMODE 24, DAT ON, SUPERVISOR STATE)
  Disabled for PER
 ASID(X'001A') DAB422. IGC0005E+1422 IN PLPA
ASCB26 at FB5D00, JOB(TH127153), for the home ASID
ASXB26 at 8FD000 and TCB26E at 8D2AA0 for the home ASID
HOME ASID: 001A PRIMARY ASID: 001A SECONDARY ASID: 001A
 
General purpose register values
  Left halves of all registers contain zeros
 0-3  8400  84001000  008C40EB  00DAB438
 4-7  008C4420  008C4474  008C4428  008C40B0
8-11 008FF708  008CA088  00F4DF78  008C5A6C
  12-15 008C45E4  00027988  80DAB328  0004
 
Access register values
  0-3  008FB37C      
  4-7        
 8-11       
   12-15       
 
Control register values
   0-1  0082_9F98EE20  _7BE08007
   2-3  _151A0700  0002_00C0001A
   4-5  0002_001A  _7EEF4680
   6-7  _  _7BE08007
   8-9  _  _
  10-11 _  _
  12-13 _057E93E7  _7BE08007
  14-15 _DF8FEEF3  _7F670010

Apologies for the staggered display.
Any help would be appreciated.
Regards, Pierre.

Re: Logical Nor (¬) in ASCII-based code pages?

[Rick Troth]

On 5/8/23 14:48, Phil Smith III wrote:

Seymour J Metz wrote, in part:

You seem to be confirming what I wrote; if the locale is UTF-8 then
your character data should be UTF-8. The ¬ character in UTF-8 has a
different encoding from the ¬ character in Unicode, so there is no
issue of a zero octet. '00AC'X is not a valid UTF-8 string.

There is no “encoding” “in Unicode”. That’s the point, and is why you can’t say 
“AC” and expect it to be meaningful. Folks might guess, but (especially with 
endianness) might get it wrong.

‘00ac’x is indeed invalid as a UTF-8 encoded value, but it’s not the 00 that’s 
bad (that’s fine, it’s a null): it’s the AC, which is invalid because the top 
two bits are 10 and that means it’s a continuation byte. So a UTF-8 parser 
chugs along, sees the 00 and says “OK, good, that’s a single-byte encoding of a 
null”. But then it looks at the AC and says “Hey, this is supposed to be a 
continuation, and I’m not IN a multi-byte encoded character, that’s no good”. 
(One of the cool things about UTF-8 is that, assuming proper UTF-8, you can 
start in the middle of a string and, if you find you’re at a continuation byte, 
you can back up to the first byte in the tuple and start from there!)

The above assumes big-endian, of course.

I’m’a keep harping on “Unicode is not an encoding” because it isn’t and it 
matters. Former manager beat that into my head, and it took a while for me to 
get it, so if you’ve bothered to read this far and feel like it’s an artificial 
distinction, I dig. It’s not.



Phil's right. Unicode is not an encoding.
UFT-8 is an encoding of Unicode which fits nicely in many historically 
8-bit spaces. UTF-8 allows the Ukrainians to use Cyrillic (one of many 
character sets in Unicode) in their web pages without having to play 
musical code pages.


If any given system is trying to process a UTF-8 stream and comes across 
00AC (at end of input, THAT'S IMPORTANT), it will treat the 00 as NULL 
and move along, then will fail on AC and either 1) throw an error, 2) 
try to cope (treating it as ISO-8859-1, maybe), or 3) ignore that byte. 
In no case can a UTF-8 processor "do the right thing" with just AC.


In sequence, AC is one of many continuation indicators. The UTF-8 
processor expects more. If it finds more, it WON'T interpret that as 
logical not. If it doesn't find more, then see previous paragraph.





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



-- R; <><

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

Re: DSFS User's Guide? (was: JES2 Submitlib ...)

[Paul Gilmartin]

On Wed, 10 May 2023 22:07:47 -0500, Paul Gilmartin wrote:
>
>There are just two manuals describing DSFS:
>z⧸OS Data Set File System Administration
>z⧸OS Data Set File System Messages and Codes
>
>DSFS is not mentioned by that initialism in the UNIX Command Ref. nor in the 
>UNIX User's Guide.
>There are characteristics of DSFS that are more relevant to end users than to 
>administrators.
>
I have received a pointer off-list (Thanks!)
to .

That's a topic in "UNIX System Services Planning".

o Again, a title likely to escape the attention of the end user ("Planning 
ain't my job.")

o The entire content of the topic is:
Data Set File System (DSFS)
With z/OS Data Set File System (DSFS), z/OS UNIX applications can access data 
sets by presenting
the data sets as a tree-structured file system that is mounted at mount point 
/dsfs in the z/OS UNIX file system tree. A utility file system is used by DSFS 
to contain POSIX information about the data sets accessed by applications to 
assist in the presentation of data sets as a tree in the z/OS UNIX file system 
space.

"POSIX" could mislead the reader to believe that DSFS is a POSIX-conformant 
file system.  The topic
should contain at least a hedge such as "with some restrictions."

-- 
gil

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

Re: Logical Nor (¬) in ASCII-based code pages?

[Rick Troth]

Unicode is the way to go in this case. In that space, logical not is 
"U+00AC", so the AA you're seeing is wrong.


In the 8-bit days (prior to Unicode), I would recommend ISO 8859-1 (so 
called "Western Latin 1"). There too, logical not is 0xAC.


Does this help?

-- R; <><


On 5/7/23 09:27, Seymour J Metz wrote:

I've seen Logical Not (¬) at AA and at AC. Are there and ASCII-based code pages 
that have it at a third position? Put another way, is there a third code point 
that ooRexx and Regina should recognize as ¬?



--
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: ispf , way to achieve the last ispf msgid from rexx

[Mike Shaw]

Weizman,

What is the context in which your REXX exec is executing? Is it executing
as an ISPF edit macro, or in some other context?

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.



On Thu, May 11, 2023, 1:23 AM Weizman arbel  wrote:

> Hello  ,
>
> from rexx
> Which command / way to achieve the last ispf msgid
>
> example:
> The result of the command  msgid
> ' The message ID of the last message was "ISRE017 " '
>
> I would like to achieve the  "ISRE017"
> from rexx
>
>
> thanks,
>weizman
>
> --
> 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: ispf , way to achieve the last ispf msgid from rexx

[Schmitt, Michael]

I think you're out of luck.

The normal method would be to retrieve variable ZERRMSG, which gives you the 
message id.

But ISPF only sets ZERRMSG if the ISPF service returns a return code of 8 or 
higher. Saving a data set isn't an error, so it doesn't set ZERRMSG.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Weizman arbel
Sent: Thursday, May 11, 2023 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ispf , way to achieve the last ispf msgid from rexx

>Have you looked at ZERRMSG, ZERRSM, and ZERRL?
It takes an effect when there is an error/message
And it doesn't return
the last MSGID.
MSGID Includes the last message code (code-id)
for example: after save command Inside edit dataset the message is  "Data set 
saved"   the msgid="ISRE017 "
I would like the message code "ISRE017 "




On Thu, 11 May 2023 10:10:18 +, Seymour J Metz  wrote:

>Have you looked at ZERRMSG, ZERRSM, and ZERRL?
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Weizman arbel [wwar...@gmail.com]
>Sent: Thursday, May 11, 2023 1:23 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: ispf , way to achieve the last ispf msgid from rexx
>
>Hello  ,
>
>from rexx
>Which command / way to achieve the last ispf msgid
>
>example:
>The result of the command  msgid
>' The message ID of the last message was "ISRE017 " '
>
>I would like to achieve the  "ISRE017"
>from rexx
>
>
>thanks,
>   weizman
>
>--
>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: ispf , way to achieve the last ispf msgid from rexx

[Weizman arbel]

>Have you looked at ZERRMSG, ZERRSM, and ZERRL?
It takes an effect when there is an error/message
And it doesn't return
the last MSGID. 
MSGID Includes the last message code (code-id)
for example: after save command Inside edit dataset the message is  "Data set 
saved"   the msgid="ISRE017 " 
I would like the message code "ISRE017 "




On Thu, 11 May 2023 10:10:18 +, Seymour J Metz  wrote:

>Have you looked at ZERRMSG, ZERRSM, and ZERRL?
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Weizman arbel [wwar...@gmail.com]
>Sent: Thursday, May 11, 2023 1:23 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: ispf , way to achieve the last ispf msgid from rexx
>
>Hello  ,
>
>from rexx
>Which command / way to achieve the last ispf msgid
>
>example:
>The result of the command  msgid
>' The message ID of the last message was "ISRE017 " '
>
>I would like to achieve the  "ISRE017"
>from rexx
>
>
>thanks,
>   weizman
>
>--
>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: IBM announcement letter summary

[John McKown]

I hadn't seen that. But it's no worse than most other companies. Not that
it's good. I wonder if it was via "social engineering". I need to
double check. Thanks for letting me know.

On Thu, May 11, 2023, 09:59 Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> Yeah I see.
>
> United HealthCare reports data breach that may have revealed customers'
> personal information. United HealthCare made customers aware of a data
> breach on Friday, which temporarily allowed access to personal information
> for those enrolled in the company's healthcare plans.May 1, 2023
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Thursday, May 11, 2023, 10:10 AM, John McKown <
> john.archie.mck...@gmail.com> wrote:
>
> UHG is very security conscious. I'm not saying they could never be hacked,
> because almost anything on the Internet can be. But they are definitely NOT
> "low hanging fruit". Even a current z/OS system, running FOSS software &
> which has a direct Internet connection could be hacked. IMO.
>
> On Wed, May 10, 2023, 11:28 Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>
> > That’s like saying global warming is a hoax because it was below zero in
> > (insert your city) today.
> >
> > As this brief survey of the mainframe's place in the current IT landscape
> > shows, “big iron” is not going away any time soon. In fact, according to
> > Allied Market Research, the global mainframe market is expected to reach
> a
> > staggering $2.90 billion by 2025.Nov 16, 2022
> >
> > I can’t wait for the inevitable hack in which UHG’s millions of customers
> > have their data stolen. Might have to switch my supplemental plan.
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Wednesday, May 10, 2023, 12:08 PM, John McKown <
> > john.archie.mck...@gmail.com> wrote:
> >
> > I can say that UHG (United Health Group) is eliminating their z machines.
> > The one I worked on is gone. The data was ported to something called
> > Facets, a vendor product. The historical reports were put in some sort of
> > archive tool.
> >
> > I cannot say with total confidence, but I've been told they are going
> pure
> > Wintel.
> >
> > On Wed, May 10, 2023, 10:11 Bill Johnson <
> > 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > > Last IBM earnings in April indicated z sales were up 7%. From the
> > earnings
> > > report, “sales of Z mainframe computer systems increased by 7%
> following
> > > the release in May of the Z16 model.”
> > > But, I’m not enthused about IBM (the company) at all. In fact I stated
> > the
> > > stock has traded in a range of 120-140 for awhile and I wouldn’t invest
> > in
> > > it, but did trade it once or twice.
> > > What I am enthused by is the likelihood of the mainframe being the
> > > platform of choice by real banks, healthcare companies, insurance
> > > companies, big retailers, and others, for decades into the future, long
> > > past our lifetimes.
> > >
> > >
> > > Sent from Yahoo Mail for iPhone
> > >
> > >
> > > On Wednesday, May 10, 2023, 10:09 AM, Mohammad Khan <
> > > 047f0e31a222-dmarc-requ...@listserv.ua.edu> wrote:
> > >
> > > But Bill definitely does and almost makes up for IBM's failing with his
> > > abundant enthusiasm !
> > >
> > > On Tue, 9 May 2023 12:21:03 -0500, John McKown <
> > > john.archie.mck...@gmail.com> wrote:
> > >
> > > 
> > > >IMO, IBM doesn't really care about that much about z anymore.
> > > 
> > >
> > > mkk
> > >
> > > PS: Not Friday yet but it's the hump-day so are almost there :)
> > >
> > > --
> > > 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
> >
>
> --
> 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 

Re: IBM announcement letter summary

[Bill Johnson]

Yeah I see.

United HealthCare reports data breach that may have revealed customers' 
personal information. United HealthCare made customers aware of a data breach 
on Friday, which temporarily allowed access to personal information for those 
enrolled in the company's healthcare plans.May 1, 2023


Sent from Yahoo Mail for iPhone


On Thursday, May 11, 2023, 10:10 AM, John McKown  
wrote:

UHG is very security conscious. I'm not saying they could never be hacked,
because almost anything on the Internet can be. But they are definitely NOT
"low hanging fruit". Even a current z/OS system, running FOSS software &
which has a direct Internet connection could be hacked. IMO.

On Wed, May 10, 2023, 11:28 Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> That’s like saying global warming is a hoax because it was below zero in
> (insert your city) today.
>
> As this brief survey of the mainframe's place in the current IT landscape
> shows, “big iron” is not going away any time soon. In fact, according to
> Allied Market Research, the global mainframe market is expected to reach a
> staggering $2.90 billion by 2025.Nov 16, 2022
>
> I can’t wait for the inevitable hack in which UHG’s millions of customers
> have their data stolen. Might have to switch my supplemental plan.
>
> Sent from Yahoo Mail for iPhone
>
>
> On Wednesday, May 10, 2023, 12:08 PM, John McKown <
> john.archie.mck...@gmail.com> wrote:
>
> I can say that UHG (United Health Group) is eliminating their z machines.
> The one I worked on is gone. The data was ported to something called
> Facets, a vendor product. The historical reports were put in some sort of
> archive tool.
>
> I cannot say with total confidence, but I've been told they are going pure
> Wintel.
>
> On Wed, May 10, 2023, 10:11 Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Last IBM earnings in April indicated z sales were up 7%. From the
> earnings
> > report, “sales of Z mainframe computer systems increased by 7% following
> > the release in May of the Z16 model.”
> > But, I’m not enthused about IBM (the company) at all. In fact I stated
> the
> > stock has traded in a range of 120-140 for awhile and I wouldn’t invest
> in
> > it, but did trade it once or twice.
> > What I am enthused by is the likelihood of the mainframe being the
> > platform of choice by real banks, healthcare companies, insurance
> > companies, big retailers, and others, for decades into the future, long
> > past our lifetimes.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Wednesday, May 10, 2023, 10:09 AM, Mohammad Khan <
> > 047f0e31a222-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > But Bill definitely does and almost makes up for IBM's failing with his
> > abundant enthusiasm !
> >
> > On Tue, 9 May 2023 12:21:03 -0500, John McKown <
> > john.archie.mck...@gmail.com> wrote:
> >
> > 
> > >IMO, IBM doesn't really care about that much about z anymore.
> > 
> >
> > mkk
> >
> > PS: Not Friday yet but it's the hump-day so are almost there :)
> >
> > --
> > 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
>

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

IBM VTS category definition

[Radoslaw Skorupka]

I just RTFM, but I'm not sure about scratch category definition in VTS 
TS7700.

I mean Expire Hold Settings and Expire Hold checkbox.

My understanding:
No expiration - scratch will *never* be reused.  ...or maybe it means 
the scratch is available for reuse immediately after transition from 
private to scratch?


Expire Hold, let's say 48h. That means the scratch will be available two 
days after the transition from private to scratch.

Q: What is the meaning of Expire Hold checkbox?




Regards
--
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: IBM announcement letter summary

[John McKown]

UHG is very security conscious. I'm not saying they could never be hacked,
because almost anything on the Internet can be. But they are definitely NOT
"low hanging fruit". Even a current z/OS system, running FOSS software &
which has a direct Internet connection could be hacked. IMO.

On Wed, May 10, 2023, 11:28 Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> That’s like saying global warming is a hoax because it was below zero in
> (insert your city) today.
>
> As this brief survey of the mainframe's place in the current IT landscape
> shows, “big iron” is not going away any time soon. In fact, according to
> Allied Market Research, the global mainframe market is expected to reach a
> staggering $2.90 billion by 2025.Nov 16, 2022
>
> I can’t wait for the inevitable hack in which UHG’s millions of customers
> have their data stolen. Might have to switch my supplemental plan.
>
> Sent from Yahoo Mail for iPhone
>
>
> On Wednesday, May 10, 2023, 12:08 PM, John McKown <
> john.archie.mck...@gmail.com> wrote:
>
> I can say that UHG (United Health Group) is eliminating their z machines.
> The one I worked on is gone. The data was ported to something called
> Facets, a vendor product. The historical reports were put in some sort of
> archive tool.
>
> I cannot say with total confidence, but I've been told they are going pure
> Wintel.
>
> On Wed, May 10, 2023, 10:11 Bill Johnson <
> 0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Last IBM earnings in April indicated z sales were up 7%. From the
> earnings
> > report, “sales of Z mainframe computer systems increased by 7% following
> > the release in May of the Z16 model.”
> > But, I’m not enthused about IBM (the company) at all. In fact I stated
> the
> > stock has traded in a range of 120-140 for awhile and I wouldn’t invest
> in
> > it, but did trade it once or twice.
> > What I am enthused by is the likelihood of the mainframe being the
> > platform of choice by real banks, healthcare companies, insurance
> > companies, big retailers, and others, for decades into the future, long
> > past our lifetimes.
> >
> >
> > Sent from Yahoo Mail for iPhone
> >
> >
> > On Wednesday, May 10, 2023, 10:09 AM, Mohammad Khan <
> > 047f0e31a222-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > But Bill definitely does and almost makes up for IBM's failing with his
> > abundant enthusiasm !
> >
> > On Tue, 9 May 2023 12:21:03 -0500, John McKown <
> > john.archie.mck...@gmail.com> wrote:
> >
> > 
> > >IMO, IBM doesn't really care about that much about z anymore.
> > 
> >
> > mkk
> >
> > PS: Not Friday yet but it's the hump-day so are almost there :)
> >
> > --
> > 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
>

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

Re: OMVS Man Pages

[Paul Gilmartin]

On Thu, 11 May 2023 07:25:07 -0500, Lionel B. Dyck  wrote:

>Please check out this IBM Idea (aka requirement) that I just posted
>regarding the OMVS Man pages and vote and/or comment
>
>https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3685
> 
It's a tough climb:  It's hard enough to get IBM to conform to standards, let 
alone
widespread prevailing conventions.

And Single UNIX says 
:

RATIONALE

It is recognized that the man utility is only of minimal usefulness as 
specified. The opinion of the standard developers was strongly divided as to 
how much or how little information man should be required to provide. They 
considered, however, that the provision of some portable way of accessing 
documentation would aid user portability. The arguments against a fuller 
specification were:

When installing FOSS, I have directed the man pages to an NFS-exported 
directory, then run a
script on Solaris to access every man page, ">/dev/null", rendering the nroff 
format into the
"cat" hierarchy for viewing on MVS.  Far from ideal.

-- 
gil

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

Re: OMVS Man Pages

[suresh chacko]

Dear Lionel,

Good post.

Regards,
Suresh

On Thu, May 11, 2023, 4:25 PM Lionel B. Dyck  wrote:

> Please check out this IBM Idea (aka requirement) that I just posted
> regarding the OMVS Man pages and vote and/or comment
>
> https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3685
>
> The prose is:
> =
>
> The current MAN command uses a z/OS unique man page format and man
> database.
> As others port tools (see the z/OS Open Tools project on Github at
> https://zosopentools.github.io/meta/#/) to run under OMVS this presents
> challenges  and a great barrier in the area of man pages as:
>
> 1. The man page format is different on OMVS when compared to the standard
> *nix man pages
>
> 2. The man database for OMVS is proprietary with no tools to update or add
> to it preventing ported/new tools from adding their man page to the
> database
>
> There are two solutions, with one better than the other.
>
> Preferred solution: Convert all existing OMVS man pages to the standard
> *nix
> format and provide a mandb tool to update the man page database.
>
> Alternate solution: Release the tool that builds the existing OMVS man page
> database.
>
> =
>
> Lionel B. Dyck <><
> Website: https://www.lbdsoftware.com
> Github: https://github.com/lbdyck
>
> “Worry more about your character than your reputation. Character is what
> you
> are, reputation merely what others think you are.”   - - - John Wooden
>
> --
> 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

OMVS Man Pages

[Lionel B. Dyck]

Please check out this IBM Idea (aka requirement) that I just posted
regarding the OMVS Man pages and vote and/or comment

https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3685

The prose is:
=

The current MAN command uses a z/OS unique man page format and man database.
As others port tools (see the z/OS Open Tools project on Github at
https://zosopentools.github.io/meta/#/) to run under OMVS this presents
challenges  and a great barrier in the area of man pages as:

1. The man page format is different on OMVS when compared to the standard
*nix man pages

2. The man database for OMVS is proprietary with no tools to update or add
to it preventing ported/new tools from adding their man page to the database

There are two solutions, with one better than the other.

Preferred solution: Convert all existing OMVS man pages to the standard *nix
format and provide a mandb tool to update the man page database.

Alternate solution: Release the tool that builds the existing OMVS man page
database.

=

Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are.”   - - - John Wooden

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

IBM LOOKAT not working?

[Allan Staller]

Classification: Confidential
Whatever message ID is entered, I receive the following response:

"Search couldn't find any matches.
Be aware of your spelling. Even a single, misspelled word can impact your 
results.
The more specific your search terms are, the better quality search results you 
will receive.

Repeat your search across all of IBM."

The subsequent search will return the requested information.

*sigh* the pea-brains in charge of documentation are getting to be quite 
annoying.
If you are going to dismantle one mechanism for another, either make an 
announcement or make it transparent.

*refrain* The ":new tools" are neither as reliable, available, or functional as 
those they replace.

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

Re: ispf , way to achieve the last ispf msgid from rexx

[Seymour J Metz]

Have you looked at ZERRMSG, ZERRSM, and ZERRL?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Weizman arbel [wwar...@gmail.com]
Sent: Thursday, May 11, 2023 1:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ispf , way to achieve the last ispf msgid from rexx

Hello  ,

from rexx
Which command / way to achieve the last ispf msgid

example:
The result of the command  msgid
' The message ID of the last message was "ISRE017 " '

I would like to achieve the  "ISRE017"
from rexx


thanks,
   weizman

--
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: XLC version? [was: RE: XLC - Weak symbols]

[David Crayford]

There are some good use cases for zCX but as a development environment you 
might as well use Linux running on a cheaper platform such as on your PC either 
native or virtual. Z/OS UNIX is tightly integrated with z/OS so is more useful 
than zCX, IMO.

> On 11 May 2023, at 3:04 pm, Mario Bezzi  
> wrote:
> 
> Wouldn't zCX address the need?
> 
> Could you develop your application under Linux elsewhere and deploy it in a 
> container with zCX?
> 
> Just curious about the difference between this and your proposed LSS.
> 
> Thanks!
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Matt Hogstrom
> Sent: Wednesday, May 10, 2023 1:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: XLC version? [was: RE: XLC - Weak symbols]
> 
> ..snip..
> 
> What  would be awesome is a new Linux System Services (LSS)  
> --
> 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: XLC version? [was: RE: XLC - Weak symbols]

[David Crayford]

> On 11 May 2023, at 11:39 am, Frank Swarbrick  
> wrote:
> 
> Is it bad because it's slow, or some other reason(s)?

Slow? 3 minutes to respond to a key-press could be considered very slow! X11 
sucks per-se, not just on z/OS. The only standout application is GIMP. 
Cross-platform GUI SDK’s and libraries and Web Applications have eclipsed it. 
I’m not sure it’s well supported on z/OS or if they have any customers. You 
would have to be nuts to even considered running a GUI using X11 passthrough on 
z/OS. 

> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> David Crayford
> Sent: Wednesday, May 10, 2023 5:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: XLC version? [was: RE: XLC - Weak symbols]
> 
>> On 11 May 2023, at 6:25 am, Frank Swarbrick  
>> wrote:
>> 
>> Has anyone here ever used X11 under z/OS?
> 
> Yes, it sucks! I don’t see the point of in in 2023 where almost all GUI 
> applications are browser based progressive web applications. Even IDE’s like 
> VS Code are HTML/TypeScript and built with Electron. ChromeOS is a Linux 
> distribution which uses Google Chrome as it’s principle UI.
> 
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Seymour J Metz
>> Sent: Wednesday, May 10, 2023 12:36 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: XLC version? [was: RE: XLC - Weak symbols]
>> 
>> Current versions of, e.g., bash, go, ooRexx, perl, python, ruby, rust, x11.
>> 
>> 
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>> 
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
>> behalf of Farley, Peter 
>> [031df298a9da-dmarc-requ...@listserv.ua.edu]
>> Sent: Wednesday, May 10, 2023 12:34 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: XLC version? [was: RE: XLC - Weak symbols]
>> 
>> "Install bash" is not a possibility in some shops.  IBM needs to make bash 
>> available (and supported) in ALL delivered/updated z/OS systems, as a 
>> standard part of z/OS, so that there is no choice in the matter.  Ditto for 
>> all the other necessary GNU utilities of course.
>> 
>> Again, just my USD$0.02.
>> 
>> Peter
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Phil Smith III
>> Sent: Wednesday, May 10, 2023 12:23 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: XLC version? [was: RE: XLC - Weak symbols]
>> 
>> Peter Farley wrote:
>>> Well, if Open XL C/C++ is the "wave of the future" then IBM had 
>>> better plan to also buy and integrate all of Rocket's GNU ports 
>>> (especially
>>> bash) because I for one can NOT work in that @#$%!^ POSIX "sh" they 
>>> supply at the moment. It is a hideous shell to try to work in. It 
>>> does not even support using the arrow keys to recall previous 
>>> commands, the backspace key does not work to let you fix command text 
>>> . . . I could go on, but what's the point. It is just plain awful.
>> 
>> Install bash and use that. Not disagreeing, it *is* awful. if IBM is still 
>> serious about USS they need to spend a (relatively) SMALL amount of effort 
>> to add standard things like bash, curl, and dos2unix. It's a huge blocker to 
>> anyone trying to do real work there.
>> --
>> 
>> This message and any attachments are intended only for the use of the 
>> addressee and may contain information that is privileged and confidential. 
>> If the reader of the message is not the intended recipient or an authorized 
>> representative of the intended recipient, you are hereby notified that any 
>> dissemination of this communication is strictly prohibited. If you have 
>> received this communication in error, please notify us immediately by e-mail 
>> and delete the message and any attachments from your system.
>> 
>> --
>> 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
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN 

Re: XLC version? [was: RE: XLC - Weak symbols]

[Mario Bezzi]

Wouldn't zCX address the need?

Could you develop your application under Linux elsewhere and deploy it in a 
container with zCX?

Just curious about the difference between this and your proposed LSS.

Thanks!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Wednesday, May 10, 2023 1:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: XLC version? [was: RE: XLC - Weak symbols]

..snip..

What  would be awesome is a new Linux System Services (LSS)  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN