Re: Hex (was: Stupid JCL question)

[Paul Gilmartin]

On Sun, 24 Dec 2023 14:18:34 -0600, Michael Oujesky wrote:

>Just as an aside, the default EBCDIC to ASCIIi translation table in
>FTP has issues with some special characters.  We used CONVXLAT
>against TCPIP.SEZATCPX(EUS) to create one that works for the texts we
>have,  Then in the FTP control statements, used LOCSITE SBDataconn=
>to specify use of the created translation table for the transfer.
> 
Could that not have been done simply by supplying the correct:
(file_system_codepage,network_transfer_codepage)
in the SBDATACONN command:

with no need to "creat a translation table"?

The proper code pages according to:

appear to be "EUS   United States with Euro support 858<->1140"

-- 
gil

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

Re: Hex (was: Stupid JCL question)

[Michael Oujesky]

At 03:21 PM 12/24/2023, Paul Gilmartin wrote:


On Sun, 24 Dec 2023 14:18:34 -0600, Michael Oujesky wrote:

>Just as an aside, the default EBCDIC to ASCIIi translation table in
>FTP has issues with some special characters.  We used CONVXLAT
>against TCPIP.SEZATCPX(EUS) to create one that works for the texts we
>have,  Then in the FTP control statements, used LOCSITE SBDataconn=
>to specify use of the created translation table for the transfer.
>


Nope, kept it in it's own dataset.


Did you need to create your own table?  Did you need to add it to LNKLST?


Nope, just used EUS from the standard TCPIP library without any 
tweaks.  Just pointed to it's own sequential file, but would probably 
install it via a USERMOD if were going to make it the default text 
translation table.



Do you have unusual code pages?


Nope, just using the original system default.


More easily, I have used SBDATACONN(IBM-1047,ISO8859-1)


More absurdly, in 

When accessing z/OS UNIX files, you must specify the OEMVS311 
translation table ...

"must"?  IOW, IBM's default doesn't work.

--
gil

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


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

Re: CDE Extension for RMODE 64

[Paul Gilmartin]

On Sun, 24 Dec 2023 19:01:06 -0500, Joseph Reichman wrote:

>Just trying to figure if a module is rmode 64
> 
AMBLIST?

-- 
gil

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

Re: Stupid JCL question

[Seymour J Metz]

Yes, but z/OS support multiple code pages. Not even the letters have unique 
encoding.

> That's x'c2  ac'.

That's the UTF-8 encoding of U+00AC; Does Regina support UTF-8 or any other 
encoding of Unicode? What happens if you translate your source to ISO-8859-1 or 
-15?

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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, December 24, 2023 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stupid JCL question

On Sun, 24 Dec 2023 14:15:49 +, Seymour J Metz  wrote:

>No. Code points can be expressed in hex; characters cannot.
>
It depends.  Much IBM literature uses "character" to mean what other cultures
call "octet".  And Unicode documentation shows several representations
for characters, including hex.

>What is 'D0'X? Without knowing the code page, no answer is possible.
>
>This is not limited to EBCDIC on z; n  the PC world, there are two different 
>encodings for logical Not, which is an issue for older implemntations of Rexx; 
>I believe that all of the newest versions recognize both 'AA'X  and 'AC'X.
>
In "regina.pdf", I see: "¬ Logical Not".  That's x'c2  ac'.  But when I 
copy/paste it,
it looks OK on my desktop, but  Regina gets syntax errors.  I prefer 
documentation
with usable examples.

--
gil

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


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

Re: CDE Extension for RMODE 64

[Joseph Reichman]

Just trying to figure if a module is rmode 64

Joe Reichman


On Sun, Dec 24, 2023 at 7:00 PM Seymour J Metz  wrote:

> SPLIT? Or is that only 24/31?
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Joseph Reichman 
> Sent: Sunday, December 24, 2023 6:34 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CDE Extension for RMODE 64
>
> HI
>
> If bit CDCEX in the CDE  meaning there is an CDE extension would that imply
> the module is RMODE 64  since CDXEntpt64 is a double word
>
> thanks
>
> --
> 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: CDE Extension for RMODE 64

[Seymour J Metz]

SPLIT? Or is that only 24/31?

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


From: IBM Mainframe Discussion List  on behalf of 
Joseph Reichman 
Sent: Sunday, December 24, 2023 6:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CDE Extension for RMODE 64

HI

If bit CDCEX in the CDE  meaning there is an CDE extension would that imply
the module is RMODE 64  since CDXEntpt64 is a double word

thanks

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

CDE Extension for RMODE 64

[Joseph Reichman]

HI

If bit CDCEX in the CDE  meaning there is an CDE extension would that imply
the module is RMODE 64  since CDXEntpt64 is a double word

thanks

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

Re: RETRY - was ARR and CSVQUERY

[Seymour J Metz]

Before CT and GTF, if they're running? Does yorr strategy changee between SRB 
and TCB?

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


From: IBM Mainframe Discussion List  on behalf of Ed 
Jaffe 
Sent: Sunday, December 24, 2023 4:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RETRY - was ARR and CSVQUERY

On 12/24/2023 9:35 AM, Tom Brennan wrote:
> Thanks Peter!  Yes, it was the surprise of an 0C4 when I expected 0C1.
> Sometimes when totally confusing things like that happen I first
> assume the computer itself is at fault, not the code I'm working on.
> And guess what, it's always the code :)

This is why the first thing I look at right after inspecting PSW and
registers in an SVC dump is the System Trace. I reiterate this on slide
12 of this presentation:

https://secure-web.cisco.com/15OJFhXZDjMhrQH_mFHa_s-M5l5D_KNgHnn34lYPQr2DLLw39aC-U8HA4M9HnDTWZyAINKRf4RF-ED2GMLttRFL2LoKo0--faVnohK9ntpwRffttftzWF1O2Xyb41Tj_LrcU84hJK8qtfDb9h34LCijAbH9G9X-Vid_-2gE3fdYYiQ-1eTd0JZhbTd7OmAjNb2NvZl5kh3Hbd9lWkd_Yd4mi6op2YbI7sp_U_KXuO9AV-oA24o4AQ3b52X4yUstf2BsSNER4GETGFJQG9fNQFoCzhOPCGly8oWC7UzAv6ZRR54Z3Cw1uOzrdjx9f-4cVArpbeGfQPzM6COtRLJPhykSHcqI3SgVWKPvRCap9pxw3fuLyoPfMzsEWHwUHC4VtFyoyn69oiRS_xpfRDfOPev3xM_3LNvv1_nSztEkl_KBFf7Z7xfHODpR_FHnL6rsG4/https%3A%2F%2Fphoenixsoftware.com%2Fftp%2Fdemo%2FThe%2520MVS%2520System%2520Trace.pdf

I search from the top for the word "before" and then look from that
point in the trace for "RCVY" -- or just an asterisk ("*") if "RCVY" not
found -- as part of my root cause analysis.

~95% of the time, I see in the trace exactly what I expect to see based
on the problem description. The other ~5% of the time I see something
unexpected that provides unique insight.

I don't know if my approach is a common or prevailing one, but it has
served me well in recent years...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1l-dkjgajolIV_jdPjvV0NyBcIxIl26Yd2Gs4naE1T6K3zAJD6EumPhpvzHpuo6wjUpU8d4bHxQ8yoJlwuCx3_mYbR0sBFuIjKu8W9sY5MyVltZpG2xdf-8QniHvSa5OD6sZqM21vQEDm7gCPKP-LQFCGYe8s7oemCIkvxk_mVAYTYRyn36aYzs09fV_mRBFJ9QY9D8CPseVZAeAe3B8TIEBENJcO5XOGjbFZPB9VS_gCSdeZ_SvbW1StOyxL1z2rDw8zFgv4lBknazK1VtUeOLZWW0YnkFFjEcK2Bpvq9pLh0Ww6r4MNMzT6TWdUnKH-nNtWFAsA5ojy7lLgzmaYztqbJ_5GHiZl6G3ZzFqyE7uuAshJ_NTP7mLscSsOUJ2cHZPz-ucx2QfQp0nzsDTUu6JbbhAy4-CXKJ41PftkZGxy3q4HmGMW3dWCdOqtOeNC/https%3A%2F%2Fwww.phoenixsoftware.com%2F



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



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

Re: Hex (was: Stupid JCL question)

[Paul Gilmartin]

On Sun, 24 Dec 2023 14:18:34 -0600, Michael Oujesky wrote:

>Just as an aside, the default EBCDIC to ASCIIi translation table in
>FTP has issues with some special characters.  We used CONVXLAT
>against TCPIP.SEZATCPX(EUS) to create one that works for the texts we
>have,  Then in the FTP control statements, used LOCSITE SBDataconn=
>to specify use of the created translation table for the transfer.
>
Did you need to create your own table?  Did you need to add it to LNKLST?
Do you have unusual code pages?
More easily, I have used SBDATACONN(IBM-1047,ISO8859-1)


More absurdly, in 

When accessing z/OS UNIX files, you must specify the OEMVS311 translation 
table ...
"must"?  IOW, IBM's default doesn't work.

-- 
gil

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

Re: RETRY - was ARR and CSVQUERY

[Ed Jaffe]

On 12/24/2023 9:35 AM, Tom Brennan wrote:
Thanks Peter!  Yes, it was the surprise of an 0C4 when I expected 0C1. 
Sometimes when totally confusing things like that happen I first 
assume the computer itself is at fault, not the code I'm working on.  
And guess what, it's always the code :)


This is why the first thing I look at right after inspecting PSW and 
registers in an SVC dump is the System Trace. I reiterate this on slide 
12 of this presentation:


https://phoenixsoftware.com/ftp/demo/The%20MVS%20System%20Trace.pdf

I search from the top for the word "before" and then look from that 
point in the trace for "RCVY" -- or just an asterisk ("*") if "RCVY" not 
found -- as part of my root cause analysis.


~95% of the time, I see in the trace exactly what I expect to see based 
on the problem description. The other ~5% of the time I see something 
unexpected that provides unique insight.


I don't know if my approach is a common or prevailing one, but it has 
served me well in recent years...



--
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: Hex (was: Stupid JCL question)

[Michael Oujesky]

Just as an aside, the default EBCDIC to ASCIIi translation table in 
FTP has issues with some special characters.  We used CONVXLAT 
against TCPIP.SEZATCPX(EUS) to create one that works for the texts we 
have,  Then in the FTP control statements, used LOCSITE SBDataconn= 
to specify use of the created translation table for the transfer.


Michael

At 03:42 PM 12/22/2023, Paul Gilmartin wrote:


On Fri, 22 Dec 2023 16:23:31 -0500, Bob Bridges wrote:

>Just to be pedantic, aren't ~all~ characters hex characters?
>
I think the only hex characters are 0-9 and A-F.

> ... That is, they can be expressed in hex.  I suppose (but I'm 
not sure) that "non-hex character" is intended to mean a character 
that can be expressed directly, eg a space can be expressed as 
'40'x or as ' '.  Whereas a tab character in EBCDIC needs to show 
up as '05'x; there's no way to insert it into my data with the  character.

>
It's easy if you use the right editor.

--
gil

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


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

Re: RETRY - was ARR and CSVQUERY

[Binyamin Dissen]

Or the hardware.

Certain machine checks while masked will force a check-stop.

On Sun, 24 Dec 2023 12:58:06 -0600 Jon Perryman  wrote:

:>Hi Tom,

:>I think Peter misinterpreted your question because you provided too much 
information.

:>> Peter Relson wrote:
:>> I'm now thinking you just meant that you were surprised that the recovery 
routine did not complete successfully.

:>I think you are asking the academic question if there is a time when RTM is 
disabled or inactive. Or if you can encounter a situation where RTM is disabled 
or inactive. Maybe you can form your question in terms of RTM behavior that you 
want to understand.

:>To clarify LPAR DISABLED WAIT state, I believe it's part of RTM. While it's a 
drastic form of recovery, the LPAR should never be left running random 
instructions. My point was that I believe that RTM always provides some sort of 
recovery even if the recovery is not actual recovery.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: RETRY - was ARR and CSVQUERY

[Jon Perryman]

Hi Tom,

I think Peter misinterpreted your question because you provided too much 
information.

> Peter Relson wrote:
> I'm now thinking you just meant that you were surprised that the recovery 
> routine did not complete successfully.

I think you are asking the academic question if there is a time when RTM is 
disabled or inactive. Or if you can encounter a situation where RTM is disabled 
or inactive. Maybe you can form your question in terms of RTM behavior that you 
want to understand.

To clarify LPAR DISABLED WAIT state, I believe it's part of RTM. While it's a 
drastic form of recovery, the LPAR should never be left running random 
instructions. My point was that I believe that RTM always provides some sort of 
recovery even if the recovery is not actual recovery.

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

Re: RETRY - was ARR and CSVQUERY

[Jay Maynard]

Doggone computers...durn things always do what you tell them to.

On Sun, Dec 24, 2023 at 11:35 AM Tom Brennan 
wrote:

> Thanks Peter!  Yes, it was the surprise of an 0C4 when I expected 0C1.
> Sometimes when totally confusing things like that happen I first assume
> the computer itself is at fault, not the code I'm working on.  And guess
> what, it's always the code :)
>
> On 12/24/2023 5:58 AM, Peter Relson wrote:
> > Tom B wrote
> > 
> > I was referring to my experience with a JES2 exit which setup its own
> > recovery routine.  In that code you could see it free any getmain'd
> > memory, etc. like you mentioned.  But also in that code was an error
> > that caused an 0C4.  So when the x'00' I added for temporary debugging
> > ran that user-coded recovery routine, I was surprised to get an 0C4
> > instead and had to fix the recovery routine.
> >
> > So of course JES2 had its own recovery routine in place that handled
> > the 0C4 and we got a dump and JES2 went on its merry way, perhaps after
> > disabling that exit (I can't remember).
> > 
> >
> > I took a weird view of what I suspect you really meant by "0C4 instead".
> I'm now thinking
> > you just meant that you were surprised that the recovery routine did not
> complete successfully.
> > But in case you were thinking of what happened to come to my mind,
> here's some info:
> >
> > When the x'00' "instruction" was executed, it would have gotten an
> operation exception
> > and the most recently established recovery routine (see "special-case"
> below) would have gotten control for the 0C1.
> > Its SDWA would have shown that. And TCBCMPC would be x'0C1000'.
> >
> > If that recovery routine then took some exception that resulted in an
> 0C4, a newer recovery routine (established by this recovery routine) or, in
> the absence of such, the next-oldest recovery routine would have gotten
> control for the 0C4. Its SDWA would have shown that . TCBCMPC would now be
> x'0C4000'.
> >
> > Special-Case: if you have established SPIE/ESPIE for a program
> interrupt, that exit will get control even if there is a newer-established
> ESTAE-type recovery routine.
> >
> > 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
>


-- 
Jay Maynard

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

Re: RETRY - was ARR and CSVQUERY

[Tom Brennan]

Thanks Peter!  Yes, it was the surprise of an 0C4 when I expected 0C1. 
Sometimes when totally confusing things like that happen I first assume 
the computer itself is at fault, not the code I'm working on.  And guess 
what, it's always the code :)


On 12/24/2023 5:58 AM, Peter Relson wrote:

Tom B wrote

I was referring to my experience with a JES2 exit which setup its own
recovery routine.  In that code you could see it free any getmain'd
memory, etc. like you mentioned.  But also in that code was an error
that caused an 0C4.  So when the x'00' I added for temporary debugging
ran that user-coded recovery routine, I was surprised to get an 0C4
instead and had to fix the recovery routine.

So of course JES2 had its own recovery routine in place that handled
the 0C4 and we got a dump and JES2 went on its merry way, perhaps after
disabling that exit (I can't remember).


I took a weird view of what I suspect you really meant by "0C4 instead". I'm 
now thinking
you just meant that you were surprised that the recovery routine did not 
complete successfully.
But in case you were thinking of what happened to come to my mind, here's some 
info:

When the x'00' "instruction" was executed, it would have gotten an operation 
exception
and the most recently established recovery routine (see "special-case" below) 
would have gotten control for the 0C1.
Its SDWA would have shown that. And TCBCMPC would be x'0C1000'.

If that recovery routine then took some exception that resulted in an 0C4, a 
newer recovery routine (established by this recovery routine) or, in the 
absence of such, the next-oldest recovery routine would have gotten control for 
the 0C4. Its SDWA would have shown that . TCBCMPC would now be x'0C4000'.

Special-Case: if you have established SPIE/ESPIE for a program interrupt, that 
exit will get control even if there is a newer-established ESTAE-type recovery 
routine.

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: Stupid JCL question

[Paul Gilmartin]

On Sun, 24 Dec 2023 14:15:49 +, Seymour J Metz  wrote:

>No. Code points can be expressed in hex; characters cannot. 
> 
It depends.  Much IBM literature uses "character" to mean what other cultures
call "octet".  And Unicode documentation shows several representations
for characters, including hex.

>What is 'D0'X? Without knowing the code page, no answer is possible.
>
>This is not limited to EBCDIC on z; n  the PC world, there are two different 
>encodings for logical Not, which is an issue for older implemntations of Rexx; 
>I believe that all of the newest versions recognize both 'AA'X  and 'AC'X.
>
In "regina.pdf", I see: "¬ Logical Not".  That's x'c2  ac'.  But when I 
copy/paste it,
it looks OK on my desktop, but  Regina gets syntax errors.  I prefer 
documentation
with usable examples.

-- 
gil

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

Re: Stupid JCL question

[Seymour J Metz]

No. Code points can be expressed in hex; characters cannot. 

What is 'D0'X? Without knowing the code page, no answer is possible.

This is not limited to EBCDIC on z; in the PC world, there are two different 
encodings for logical Not, which is an issue for older implemntations of Rexx; 
I believe that all of the newest versions recognize both 'AA'X  and 'AC'X.

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


From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Friday, December 22, 2023 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Stupid JCL question

Just to be pedantic, aren't ~all~ characters hex characters?  That is, they can 
be expressed in hex.  I suppose (but I'm not sure) that "non-hex character" is 
intended to mean a character that can be expressed directly, eg a space can be 
expressed as '40'x or as ' '.  Whereas a tab character in EBCDIC needs to show 
up as '05'x; there's no way to insert it into my data with the  character.

('05'x?  Yeah, I think that’s right.)

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* ...the director and the writers keep changing the script.  The actors will 
do a scene, and the director will say, "OK, that was perfect, but this time, 
Bob, instead of saying 'What's for dinner?' you say, 'Wait a minute!  Benzene 
is actually a hydrocarbon!'  And say it with a Norwegian accent.  Also, we 
think maybe your character should have no arms."  -Dave Barry, describing his 
acting debut in "Dave's World" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, December 22, 2023 15:48

A likely offender is instream NETDATA, which could have any character, even 
non-hex in any position.  Most characters are non-hex.

--- On Fri, 22 Dec 2023 15:30:03 -0500, Steve Thompson wrote:
>Oh has that come back to byte people!!  (data stream(s) having any hex
>character in any position).

--
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: RETRY - was ARR and CSVQUERY

[Peter Relson]

Tom B wrote

I was referring to my experience with a JES2 exit which setup its own
recovery routine.  In that code you could see it free any getmain'd
memory, etc. like you mentioned.  But also in that code was an error
that caused an 0C4.  So when the x'00' I added for temporary debugging
ran that user-coded recovery routine, I was surprised to get an 0C4
instead and had to fix the recovery routine.

So of course JES2 had its own recovery routine in place that handled
the 0C4 and we got a dump and JES2 went on its merry way, perhaps after
disabling that exit (I can't remember).


I took a weird view of what I suspect you really meant by "0C4 instead". I'm 
now thinking
you just meant that you were surprised that the recovery routine did not 
complete successfully.
But in case you were thinking of what happened to come to my mind, here's some 
info:

When the x'00' "instruction" was executed, it would have gotten an operation 
exception
and the most recently established recovery routine (see "special-case" below) 
would have gotten control for the 0C1.
Its SDWA would have shown that. And TCBCMPC would be x'0C1000'.

If that recovery routine then took some exception that resulted in an 0C4, a 
newer recovery routine (established by this recovery routine) or, in the 
absence of such, the next-oldest recovery routine would have gotten control for 
the 0C4. Its SDWA would have shown that . TCBCMPC would now be x'0C4000'.

Special-Case: if you have established SPIE/ESPIE for a program interrupt, that 
exit will get control even if there is a newer-established ESTAE-type recovery 
routine.

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: TCPPING for z/OS

[Seymour J Metz]

How do you react to the finger and touch commands? Are there any other *ix 
commands with suggestive names?

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


From: IBM Mainframe Discussion List  on behalf of 
Foster, Ryan 
Sent: Thursday, December 21, 2023 7:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TCPPING for z/OS

Phil,

You aren't the only one.  I had to do a double check thinking I saw "TIPPING 
for z/OS".  😊

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, December 20, 2023 18:01
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TCPPING for z/OS

WARNING - THIS IS AN EXTERNAL EMAIL



Am I the only one who keeps reading this thread subject as "TIPPING for z/OS" 
and thinks, "&deity, this tipping thing is REALLY getting out of hand!!!" ?


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