Re: Unlike data sets concatenation - revised

[Lennie Dymoke-Bradshaw]

The reference to record as a segment of a physical block is really a "logical 
record". Hence LRECL stands for "logical record length".  The "WRNG.LEN.RECORD" 
reference is speaking of physical records or block.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: 27 April 2023 00:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unlike data sets concatenation - revised

A DASD record is a physical block.  Contents of the block depend on the RECFM=, 
i.e. U for load modules, VB for variable blocked, FB for Fixed Blocked.

On Wed, Apr 26, 2023 at 6:11 PM Seymour J Metz  wrote:
>
> The DASD documentation uses the term record.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Paul Gilmartin 
> [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
> Sent: Wednesday, April 26, 2023 6:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unlike data sets concatenation - revised
>
> On Wed, 26 Apr 2023 13:44:21 -0700, Michael Stein wrote:
>
> >>  000234D0   E6D9D5C7   4BD3C5D5   4BD9C5C3   D6D9C46B   | WRNG.LEN.RECORD, 
> >> |
> >
> >A likely result from reading a block larger than the blksize.
> >
> Why does it say "RECORD" if it means "Block"?
>
> >...
> >What does the *SOURCE* DCB & JCL look like?  Do either specify LRECL 
> >and/or BLKSIZE?
> >
> Just cut the Gordian Knot and specify the largest BLKSIZE expected; even 
> 32760.
> LRECL likewise. Storage is cheap nowadays.
>
> --
> 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



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

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

[Seymour J Metz]

ObPedant For lo these many years the DASD "physical record" has actually been a 
logical record in DASD with a different architecture.

That said, in DFSMSdfp, "physical record size" refers to the block size as seen 
at the channel, not to the block size of the underlying DASD; "logical record 
size" refers to either a segment of a physical record, or, for spanned records, 
a record constructed from a sequence of such segments, and the meaning of 
"record" depends upon context.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Lennie Dymoke-Bradshaw [032fff1be9b4-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, April 27, 2023 3:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unlike data sets concatenation - revised

The reference to record as a segment of a physical block is really a "logical 
record". Hence LRECL stands for "logical record length".  The "WRNG.LEN.RECORD" 
reference is speaking of physical records or block.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: 27 April 2023 00:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unlike data sets concatenation - revised

A DASD record is a physical block.  Contents of the block depend on the RECFM=, 
i.e. U for load modules, VB for variable blocked, FB for Fixed Blocked.

On Wed, Apr 26, 2023 at 6:11 PM Seymour J Metz  wrote:
>
> The DASD documentation uses the term record.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Paul Gilmartin
> [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
> Sent: Wednesday, April 26, 2023 6:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unlike data sets concatenation - revised
>
> On Wed, 26 Apr 2023 13:44:21 -0700, Michael Stein wrote:
>
> >>  000234D0   E6D9D5C7   4BD3C5D5   4BD9C5C3   D6D9C46B   | WRNG.LEN.RECORD, 
> >> |
> >
> >A likely result from reading a block larger than the blksize.
> >
> Why does it say "RECORD" if it means "Block"?
>
> >...
> >What does the *SOURCE* DCB & JCL look like?  Do either specify LRECL
> >and/or BLKSIZE?
> >
> Just cut the Gordian Knot and specify the largest BLKSIZE expected; even 
> 32760.
> LRECL likewise. Storage is cheap nowadays.
>
> --
> 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



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

--
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: TSO Rexx C2X Incorrect Output

[David Spiegel]

Hi Peter,
I figured out the problem.
I should have coded Parse Pull to take the record off of the Stack 
(instead of Pull (which uppercases the record)).


Thanks and regards,
David

On 2023-04-24 12:11, Farley, Peter wrote:

Something else must be off in that code, maybe the offset in the substr?  I 
used Gilbert Saint-Flour's REXXTRY and got this result:

READY
REXXTRY
SAY C2X('1996160F'X)
END
1996160F

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Spiegel
Sent: Monday, April 24, 2023 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TSO Rexx C2X Incorrect Output

Hi,
I am writing a TSO Rexx Exec to Parse fields from a DCOLLECT output
(VB/32756/32760).
One statement is: created=C2x(Substr(dcollect.i,105,4))
(In DCOLLECT parlance, this is DCDCREDT).
For any date greater than 2000-01-01, I get the expected result.
But, when the field contains x'1999160F' (I BROWSEd the DCOLLECT output
to make sure), "created" has the value "19D9160F".
I'm stumped.  (The third character in the result is "D" (as in "Dog"),
instead of "9").
I'm using PCOMM (in case that matters.)
Please help.

Thank you in advance.

Regards,
David
--


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

Re: Unlike data sets concatenation - revised

[Lennie Dymoke-Bradshaw]

Fair enough 😊.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: 27 April 2023 11:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unlike data sets concatenation - revised

ObPedant For lo these many years the DASD "physical record" has actually been a 
logical record in DASD with a different architecture.

That said, in DFSMSdfp, "physical record size" refers to the block size as seen 
at the channel, not to the block size of the underlying DASD; "logical record 
size" refers to either a segment of a physical record, or, for spanned records, 
a record constructed from a sequence of such segments, and the meaning of 
"record" depends upon context.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Lennie Dymoke-Bradshaw [032fff1be9b4-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, April 27, 2023 3:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unlike data sets concatenation - revised

The reference to record as a segment of a physical block is really a "logical 
record". Hence LRECL stands for "logical record length".  The "WRNG.LEN.RECORD" 
reference is speaking of physical records or block.
Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: 27 April 2023 00:43
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unlike data sets concatenation - revised

A DASD record is a physical block.  Contents of the block depend on the RECFM=, 
i.e. U for load modules, VB for variable blocked, FB for Fixed Blocked.

On Wed, Apr 26, 2023 at 6:11 PM Seymour J Metz  wrote:
>
> The DASD documentation uses the term record.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Paul Gilmartin 
> [042bfe9c879d-dmarc-requ...@listserv.ua.edu]
> Sent: Wednesday, April 26, 2023 6:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unlike data sets concatenation - revised
>
> On Wed, 26 Apr 2023 13:44:21 -0700, Michael Stein wrote:
>
> >>  000234D0   E6D9D5C7   4BD3C5D5   4BD9C5C3   D6D9C46B   | WRNG.LEN.RECORD, 
> >> |
> >
> >A likely result from reading a block larger than the blksize.
> >
> Why does it say "RECORD" if it means "Block"?
>
> >...
> >What does the *SOURCE* DCB & JCL look like?  Do either specify LRECL 
> >and/or BLKSIZE?
> >
> Just cut the Gordian Knot and specify the largest BLKSIZE expected; even 
> 32760.
> LRECL likewise. Storage is cheap nowadays.
>
> --
> 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



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

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

IPCS formatting of I/O control blocks

[Seymour J Metz]

The last time I looked, IPCS did not format, e.g., DCB, DECB, IOB. Has that 
changed?



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

Inexplicable 0C4!

[Robin Atwood]

I have had two of these during the course of two months, so it's getting
serious!

The abend happens in my implementation of a C strupr() function when the TRE
instruction is executed:

 

 L   R3,=X'7FFF'string maximum length

 XRR0,R0  zero terminator byte 

 LA R1,UPRXtranslate table  

TST  TRE   R2,R1  fold string  

 BC 1,TSTresume translation   

 

   R0  R1 R2  R3
PSW

 0009C5EC 1AA748F8 7FFF  078D04008009BD14

 

The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog
standard. I know R3

looks dodgy, but that is because the string to be upper-cased must be zero
byte terminated. 

R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all
this, why has the instruction caused an

abend? The code lives in a server that is running all day, every day. I
wondered if the target data had been 

released by another task, but VSMDATA showed a DQE for the data's page and
no FQE for the data itself,

so the data should still be available (as I understand it). Notice R3 hasn't
changed, so the abend happened 

on the very first byte.

 

Any suggestions gratefully received!

Robin

 

 

 


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

Re: Inexplicable 0C4!

[Seymour J Metz]

Is UPRX a full 256 bytes?


From: IBM Mainframe Discussion List  on behalf of 
Robin Atwood 
Sent: Thursday, April 27, 2023 8:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Inexplicable 0C4!

I have had two of these during the course of two months, so it's getting
serious!

The abend happens in my implementation of a C strupr() function when the TRE
instruction is executed:



 L   R3,=X'7FFF'string maximum length

 XRR0,R0  zero terminator byte

 LA R1,UPRXtranslate table

TST  TRE   R2,R1  fold string

 BC 1,TSTresume translation



   R0  R1 R2  R3
PSW

 0009C5EC 1AA748F8 7FFF  078D04008009BD14



The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog
standard. I know R3

looks dodgy, but that is because the string to be upper-cased must be zero
byte terminated.

R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all
this, why has the instruction caused an

abend? The code lives in a server that is running all day, every day. I
wondered if the target data had been

released by another task, but VSMDATA showed a DQE for the data's page and
no FQE for the data itself,

so the data should still be available (as I understand it). Notice R3 hasn't
changed, so the abend happened

on the very first byte.



Any suggestions gratefully received!

Robin








--
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: TSO Rexx C2X Incorrect Output

[Paul Gilmartin]

On Thu, 27 Apr 2023 06:47:55 -0400, David Spiegel wrote:

>Hi Peter,
>I figured out the problem.
>I should have coded Parse Pull to take the record off of the Stack
>(instead of Pull (which uppercases the record)).
>
Events such as this affirm my belief in minimal munging of user data by default.
Unless the user specifies UPPER the default should be ASIS.

Everywhere.

Especially in ALLOCATE DSN(*).

Yet, you could have avoided much consternation by showing enough of your
code for readers to reproduce the problem.  Showing the "PULL" would
have been enough; C2X was not at fault.

-- 
gil

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

Re: Inexplicable 0C4!

[Binyamin Dissen]

Which flavor of 0C4?

If PIC-10/11, the address is reported.

On Thu, 27 Apr 2023 19:58:23 +0700 Robin Atwood  wrote:

:>I have had two of these during the course of two months, so it's getting
:>serious!
:>
:>The abend happens in my implementation of a C strupr() function when the TRE
:>instruction is executed:
:>
:> 
:>
:> L   R3,=X'7FFF'string maximum length
:>
:> XRR0,R0  zero terminator byte 
:>
:> LA R1,UPRXtranslate table  
:>
:>TST  TRE   R2,R1  fold string  
:>
:> BC 1,TSTresume translation   
:>
:> 
:>
:>   R0  R1 R2  R3
:>PSW
:>
:> 0009C5EC 1AA748F8 7FFF  078D04008009BD14
:>
:> 
:>
:>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog
:>standard. I know R3
:>
:>looks dodgy, but that is because the string to be upper-cased must be zero
:>byte terminated. 
:>
:>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all
:>this, why has the instruction caused an
:>
:>abend? The code lives in a server that is running all day, every day. I
:>wondered if the target data had been 
:>
:>released by another task, but VSMDATA showed a DQE for the data's page and
:>no FQE for the data itself,
:>
:>so the data should still be available (as I understand it). Notice R3 hasn't
:>changed, so the abend happened 
:>
:>on the very first byte.
:>
:> 
:>
:>Any suggestions gratefully received!
:>
:>Robin
:>
:> 
:>
:> 
:>
:> 
:>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
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: TSO Rexx C2X Incorrect Output

[David Spiegel]

Hi Gil,
You said: "...Yet, you could have avoided much consternation ..."
Shkoyach! (A short Yiddish expression similar to "Thank you" which can 
also be used facetiously.)
Had I thought (originally) that "Pull" was the issue,. I would've 
figured it out on my own.


Regards,
David

On 2023-04-27 09:35, Paul Gilmartin wrote:

On Thu, 27 Apr 2023 06:47:55 -0400, David Spiegel wrote:


Hi Peter,
I figured out the problem.
I should have coded Parse Pull to take the record off of the Stack
(instead of Pull (which uppercases the record)).


Events such as this affirm my belief in minimal munging of user data by default.
Unless the user specifies UPPER the default should be ASIS.

Everywhere.

Especially in ALLOCATE DSN(*).

Yet, you could have avoided much consternation by showing enough of your
code for readers to reproduce the problem.  Showing the "PULL" would
have been enough; C2X was not at fault.



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

Re: Inexplicable 0C4!

[Clifford McNeill]

should this load

 L   R3,=X'7FFF'string maximum length

be a load address?

 LA  R3,=X'7FFF'


On 4/27/2023 8:52 AM, Binyamin Dissen wrote:

Which flavor of 0C4?

If PIC-10/11, the address is reported.

On Thu, 27 Apr 2023 19:58:23 +0700 Robin Atwood  wrote:

:>I have had two of these during the course of two months, so it's getting
:>serious!
:>
:>The abend happens in my implementation of a C strupr() function when the TRE
:>instruction is executed:
:>
:>
:>
:> L   R3,=X'7FFF'string maximum length
:>
:> XRR0,R0  zero terminator byte
:>
:> LA R1,UPRXtranslate table
:>
:>TST  TRE   R2,R1  fold string
:>
:> BC 1,TSTresume translation
:>
:>
:>
:>   R0  R1 R2  R3
:>PSW
:>
:> 0009C5EC 1AA748F8 7FFF  078D04008009BD14
:>
:>
:>
:>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog
:>standard. I know R3
:>
:>looks dodgy, but that is because the string to be upper-cased must be zero
:>byte terminated.
:>
:>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all
:>this, why has the instruction caused an
:>
:>abend? The code lives in a server that is running all day, every day. I
:>wondered if the target data had been
:>
:>released by another task, but VSMDATA showed a DQE for the data's page and
:>no FQE for the data itself,
:>
:>so the data should still be available (as I understand it). Notice R3 hasn't
:>changed, so the abend happened
:>
:>on the very first byte.
:>
:>
:>
:>Any suggestions gratefully received!
:>
:>Robin
:>
:>
:>
:>
:>
:>
:>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


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

Re: Inexplicable 0C4!

[Clifford McNeill]

never mind, more coffee

On 4/27/2023 9:12 AM, Clifford McNeill wrote:

should this load

 L   R3,=X'7FFF'    string maximum length

be a load address?

 LA  R3,=X'7FFF'


On 4/27/2023 8:52 AM, Binyamin Dissen wrote:

Which flavor of 0C4?

If PIC-10/11, the address is reported.

On Thu, 27 Apr 2023 19:58:23 +0700 Robin Atwood  
wrote:


:>I have had two of these during the course of two months, so it's 
getting

:>serious!
:>
:>The abend happens in my implementation of a C strupr() function 
when the TRE

:>instruction is executed:
:>
:>
:>
:> L   R3,=X'7FFF'    string maximum length
:>
:> XR    R0,R0  zero terminator byte
:>
:> LA R1,UPRX    translate table
:>
:>TST  TRE   R2,R1  fold string
:>
:> BC 1,TST    resume translation
:>
:>
:>
:>   R0  R1 R2 R3
:>PSW
:>
:> 0009C5EC 1AA748F8 7FFF  078D04008009BD14
:>
:>
:>
:>The memory pointed to by R1 and R2 is addressable and in Sp0, key 
8, so bog

:>standard. I know R3
:>
:>looks dodgy, but that is because the string to be upper-cased must 
be zero

:>byte terminated.
:>
:>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given 
all

:>this, why has the instruction caused an
:>
:>abend? The code lives in a server that is running all day, every 
day. I

:>wondered if the target data had been
:>
:>released by another task, but VSMDATA showed a DQE for the data's 
page and

:>no FQE for the data itself,
:>
:>so the data should still be available (as I understand it). Notice 
R3 hasn't

:>changed, so the abend happened
:>
:>on the very first byte.
:>
:>
:>
:>Any suggestions gratefully received!
:>
:>Robin
:>
:>
:>
:>
:>
:>
:>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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


--
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: Inexplicable 0C4!

[Seymour J Metz]

No, but perhaps LGFI, avoiding the literal, would be better.


From: IBM Mainframe Discussion List  on behalf of 
Clifford McNeill <04cc09e1fcab-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, April 27, 2023 10:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inexplicable 0C4!

should this load

  L   R3,=X'7FFF'string maximum length

be a load address?

  LA  R3,=X'7FFF'


On 4/27/2023 8:52 AM, Binyamin Dissen wrote:
> Which flavor of 0C4?
>
> If PIC-10/11, the address is reported.
>
> On Thu, 27 Apr 2023 19:58:23 +0700 Robin Atwood  wrote:
>
> :>I have had two of these during the course of two months, so it's getting
> :>serious!
> :>
> :>The abend happens in my implementation of a C strupr() function when the TRE
> :>instruction is executed:
> :>
> :>
> :>
> :> L   R3,=X'7FFF'string maximum length
> :>
> :> XRR0,R0  zero terminator byte
> :>
> :> LA R1,UPRXtranslate table
> :>
> :>TST  TRE   R2,R1  fold string
> :>
> :> BC 1,TSTresume translation
> :>
> :>
> :>
> :>   R0  R1 R2  R3
> :>PSW
> :>
> :> 0009C5EC 1AA748F8 7FFF  078D04008009BD14
> :>
> :>
> :>
> :>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so bog
> :>standard. I know R3
> :>
> :>looks dodgy, but that is because the string to be upper-cased must be zero
> :>byte terminated.
> :>
> :>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all
> :>this, why has the instruction caused an
> :>
> :>abend? The code lives in a server that is running all day, every day. I
> :>wondered if the target data had been
> :>
> :>released by another task, but VSMDATA showed a DQE for the data's page and
> :>no FQE for the data itself,
> :>
> :>so the data should still be available (as I understand it). Notice R3 hasn't
> :>changed, so the abend happened
> :>
> :>on the very first byte.
> :>
> :>
> :>
> :>Any suggestions gratefully received!
> :>
> :>Robin
> :>
> :>
> :>
> :>
> :>
> :>
> :>
> :>
> :>--
> :>For IBM-MAIN subscribe / signoff / archive access instructions,
> :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> Binyamin Dissen 
> http://secure-web.cisco.com/14Z0n8HNM1J6A-lr5C6rpokRsSjYebS7TqRLaP2ymVFrOiaHNSa2hlqBFcvHHl0VbDIeh-aNPygmcDzT42x3jngWi7SaEh8HwDibZMtskCdbeJKXq7zoO4pQRGI88_ak-1oHMtvqgLSsg4gaysP9wCKEDGB2_kMrPMymBvbM3yEJvOzLCTBmyxmvBvseZlvGl20q2lZhFiEjrY_sTHlNANYCSC3O3lVSF3-_mlcXt1AyU8fj8AbTsB5RQTVlBjNdZvgB6UUBtAWXZvxDSvj3oMi695E4Luheoux66PYUau56cB07N96lPg0c42XayBMYyiG8qQedBXxiUpQ3xJvQmswCFcKkrdU7-k8L1eJOFvxf1xw7WEY4dUYszOI2lxFjLJ2EdO_QlyKUlpvBLDNrYAygarAo6Ylx8wYg2OUWmngw/http%3A%2F%2Fwww.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

--
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: Inexplicable 0C4!

[Ed Jaffe]

On 4/27/2023 5:58 AM, Robin Atwood wrote:

Any suggestions gratefully received!


Look at the TEA value in the dump (ignoring the last three nybbles).

That will tell you where in virtual storage the problem was discovered.


--
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: Inexplicable 0C4!

[Joe Monk]

"If the operation is completed with condition code 0, the contents of
general register R1 are incremented by the contents of general register R1 +
1, and then the contents of general register R1 + 1 are set to zero. If the
operation is completed with condition code 1, the contents of general
register R1 + 1 are decremented by the number of bytes processed before the
first-operand byte equal to the test byte was encountered, and the contents
of general register R1 are incremented by the same number, so that general
register R1 contains the address of the equal byte. If the operation is
completed with condition code 3, the contents of general register R1 + 1
are decremented by the number of bytes processed, and the contents of
general register R1 are incremented by the same number, so that the
instruction, when reexecuted, resumes at the next byte to be processed."

I think you may want to re-evaulate your BC processing...

Joe

On Thu, Apr 27, 2023 at 8:53 AM Binyamin Dissen 
wrote:

> Which flavor of 0C4?
>
> If PIC-10/11, the address is reported.
>
> On Thu, 27 Apr 2023 19:58:23 +0700 Robin Atwood 
> wrote:
>
> :>I have had two of these during the course of two months, so it's getting
> :>serious!
> :>
> :>The abend happens in my implementation of a C strupr() function when the
> TRE
> :>instruction is executed:
> :>
> :>
> :>
> :> L   R3,=X'7FFF'string maximum length
> :>
> :> XRR0,R0  zero terminator byte
> :>
> :> LA R1,UPRXtranslate table
> :>
> :>TST  TRE   R2,R1  fold string
> :>
> :> BC 1,TSTresume translation
> :>
> :>
> :>
> :>   R0  R1 R2  R3
> :>PSW
> :>
> :> 0009C5EC 1AA748F8 7FFF  078D04008009BD14
> :>
> :>
> :>
> :>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so
> bog
> :>standard. I know R3
> :>
> :>looks dodgy, but that is because the string to be upper-cased must be
> zero
> :>byte terminated.
> :>
> :>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all
> :>this, why has the instruction caused an
> :>
> :>abend? The code lives in a server that is running all day, every day. I
> :>wondered if the target data had been
> :>
> :>released by another task, but VSMDATA showed a DQE for the data's page
> and
> :>no FQE for the data itself,
> :>
> :>so the data should still be available (as I understand it). Notice R3
> hasn't
> :>changed, so the abend happened
> :>
> :>on the very first byte.
> :>
> :>
> :>
> :>Any suggestions gratefully received!
> :>
> :>Robin
> :>
> :>
> :>
> :>
> :>
> :>
> :>
> :>
> :>--
> :>For IBM-MAIN subscribe / signoff / archive access instructions,
> :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> 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
>

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

Re: Inexplicable 0C4!

[Seymour J Metz]

BC 1 seems to be correct.


From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Thursday, April 27, 2023 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inexplicable 0C4!

"If the operation is completed with condition code 0, the contents of
general register R1 are incremented by the contents of general register R1 +
1, and then the contents of general register R1 + 1 are set to zero. If the
operation is completed with condition code 1, the contents of general
register R1 + 1 are decremented by the number of bytes processed before the
first-operand byte equal to the test byte was encountered, and the contents
of general register R1 are incremented by the same number, so that general
register R1 contains the address of the equal byte. If the operation is
completed with condition code 3, the contents of general register R1 + 1
are decremented by the number of bytes processed, and the contents of
general register R1 are incremented by the same number, so that the
instruction, when reexecuted, resumes at the next byte to be processed."

I think you may want to re-evaulate your BC processing...

Joe

On Thu, Apr 27, 2023 at 8:53 AM Binyamin Dissen 
wrote:

> Which flavor of 0C4?
>
> If PIC-10/11, the address is reported.
>
> On Thu, 27 Apr 2023 19:58:23 +0700 Robin Atwood 
> wrote:
>
> :>I have had two of these during the course of two months, so it's getting
> :>serious!
> :>
> :>The abend happens in my implementation of a C strupr() function when the
> TRE
> :>instruction is executed:
> :>
> :>
> :>
> :> L   R3,=X'7FFF'string maximum length
> :>
> :> XRR0,R0  zero terminator byte
> :>
> :> LA R1,UPRXtranslate table
> :>
> :>TST  TRE   R2,R1  fold string
> :>
> :> BC 1,TSTresume translation
> :>
> :>
> :>
> :>   R0  R1 R2  R3
> :>PSW
> :>
> :> 0009C5EC 1AA748F8 7FFF  078D04008009BD14
> :>
> :>
> :>
> :>The memory pointed to by R1 and R2 is addressable and in Sp0, key 8, so
> bog
> :>standard. I know R3
> :>
> :>looks dodgy, but that is because the string to be upper-cased must be
> zero
> :>byte terminated.
> :>
> :>R2 points at X'D4C6C9E3E2E3404000', so the format is correct. Given all
> :>this, why has the instruction caused an
> :>
> :>abend? The code lives in a server that is running all day, every day. I
> :>wondered if the target data had been
> :>
> :>released by another task, but VSMDATA showed a DQE for the data's page
> and
> :>no FQE for the data itself,
> :>
> :>so the data should still be available (as I understand it). Notice R3
> hasn't
> :>changed, so the abend happened
> :>
> :>on the very first byte.
> :>
> :>
> :>
> :>Any suggestions gratefully received!
> :>
> :>Robin
> :>
> :>
> :>
> :>
> :>
> :>
> :>
> :>
> :>--
> :>For IBM-MAIN subscribe / signoff / archive access instructions,
> :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> 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
>

--
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: Inexplicable 0C4!

[Michael Stein]

On Thu, Apr 27, 2023 at 07:58:23PM +0700, Robin Atwood wrote:
> I have had two of these during the course of two months, so it's getting
> serious!
> 
> The abend happens in my implementation of a C strupr() function when the TRE
> instruction is executed:
> 
> TST  TRE   R2,R1  fold string  
>
> R0   R1   R2   R3PSW
> 
>  0009C5EC 1AA748F8 7FFF  078D04008009BD14

from principles of operation TRE:

  Access exceptions for the portion of the first operand to the right of
  the last byte processed may or may not be recognized. For an operand
  longer than 4K bytes, access exceptions are not recognized for locations
  more than 4K bytes beyond the last byte processed.

  Access exceptions for all 256 bytes of the second operand may be
  recognized, even if not all bytes are used.

The first operand is > 4K bytes, R2 is 1AA748F8, what's the status of
the next page?

R1 looks ok as the 2nd operand only needs to clear 256 bytes.

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

Re: Inexplicable 0C4!

[Seymour J Metz]

Is it possible that the string is in key 0 or  read-only storage?


From: IBM Mainframe Discussion List  on behalf of 
Michael Stein 
Sent: Thursday, April 27, 2023 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inexplicable 0C4!

On Thu, Apr 27, 2023 at 07:58:23PM +0700, Robin Atwood wrote:
> I have had two of these during the course of two months, so it's getting
> serious!
>
> The abend happens in my implementation of a C strupr() function when the TRE
> instruction is executed:
>
> TST  TRE   R2,R1  fold string
>
> R0   R1   R2   R3PSW
>
>  0009C5EC 1AA748F8 7FFF  078D04008009BD14

from principles of operation TRE:

  Access exceptions for the portion of the first operand to the right of
  the last byte processed may or may not be recognized. For an operand
  longer than 4K bytes, access exceptions are not recognized for locations
  more than 4K bytes beyond the last byte processed.

  Access exceptions for all 256 bytes of the second operand may be
  recognized, even if not all bytes are used.

The first operand is > 4K bytes, R2 is 1AA748F8, what's the status of
the next page?

R1 looks ok as the 2nd operand only needs to clear 256 bytes.

--
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: TSO Rexx C2X Incorrect Output

[Walt Farrell]

On Thu, 27 Apr 2023 10:01:06 -0400, David Spiegel  
wrote:

>Had I thought (originally) that "Pull" was the issue,. I would've
>figured it out on my own.

Using the tracing functions in REXX to do the debugging, rather than browsing 
the data set itself, would also have been helpful.

-- 
Walt

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

Re: TSO Rexx C2X Incorrect Output

[Paul Gilmartin]

On Thu, 27 Apr 2023 10:39:44 -0500, Walt Farrell wrote:

>On Thu, 27 Apr 2023 10:01:06 -0400, David Spiegel wrote:
>
>>Had I thought (originally) that "Pull" was the issue,. I would've
>>figured it out on my own.
>
>Using the tracing functions in REXX to do the debugging, rather than browsing 
>the data set itself, would also have been helpful.
>
Wouldn't that have shown mostly unintelligible character representation of 
binary/packed data?

> created=C2x(Substr(dcollect.i,105,4))

The problem was very nearby.  C2X() operated correctly on incorrect input.
Unfortunately, REXX provides little means to verify binary data other than
C2X() which was already under suspicion.  My inclination (admittedly post facto)
would be something like:
call charout 'tempfile', dcollect.i, 1
address SH 'od -tx1 tempfile

... using a different utility for hex conversion of the immediately proximate 
input to C2C().

-- 
gil

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

Re: TSO Rexx C2X Incorrect Output

[David Spiegel]

Hi Walt,
Yeah, I used Rexx's Trace, but, could not figure out how x'99' became x'D9'.

The error was intermittent in the sense that any date beyond 2000-01-01 
didn't have this problem.
(The reason why the error surfaced, is that x'99' is an 'r' and the Pull 
ORd it with x'40' to uppercase it.)


Regards,
David

On 2023-04-27 11:39, Walt Farrell wrote:

On Thu, 27 Apr 2023 10:01:06 -0400, David Spiegel  
wrote:


Had I thought (originally) that "Pull" was the issue,. I would've
figured it out on my own.

Using the tracing functions in REXX to do the debugging, rather than browsing 
the data set itself, would also have been helpful.



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

Re: TSO Rexx C2X Incorrect Output

[Seymour J Metz]

I'm pretty sure that trace i would have sped up the problem resolution, as Walt 
suggested.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, April 27, 2023 12:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO Rexx C2X Incorrect Output

On Thu, 27 Apr 2023 10:39:44 -0500, Walt Farrell wrote:

>On Thu, 27 Apr 2023 10:01:06 -0400, David Spiegel wrote:
>
>>Had I thought (originally) that "Pull" was the issue,. I would've
>>figured it out on my own.
>
>Using the tracing functions in REXX to do the debugging, rather than browsing 
>the data set itself, would also have been helpful.
>
Wouldn't that have shown mostly unintelligible character representation of 
binary/packed data?

> created=C2x(Substr(dcollect.i,105,4))

The problem was very nearby.  C2X() operated correctly on incorrect input.
Unfortunately, REXX provides little means to verify binary data other than
C2X() which was already under suspicion.  My inclination (admittedly post facto)
would be something like:
call charout 'tempfile', dcollect.i, 1
address SH 'od -tx1 tempfile

... using a different utility for hex conversion of the immediately proximate 
input to C2C().

--
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: TSO Rexx C2X Incorrect Output

[Paul Gilmartin]

On Thu, 27 Apr 2023 12:41:22 -0400, David Spiegel wrote:

>Hi Walt,
>Yeah, I used Rexx's Trace, but, could not figure out how x'99' became x'D9'.
>
He's suggesying that with TRACE I, sharp eyes, and intimate familiarity
with the EBCDIC character set you might have spotted that the input
to C2X() was the 4-character string '?R??' where you might have
expected '?r??', blaming the input to C2X(), not C2X() itself.

That's a long shot.

>(The reason why the error surfaced, is that x'99' is an 'r' and the Pull
>ORd it with x'40' to uppercase it.)
>
PULL is simply bad design.  Simpler is better.


>On 2023-04-27 11:39, Walt Farrell wrote:
>> ...
>> Using the tracing functions in REXX to do the debugging, rather than 
>> browsing the data set itself, would also have been helpful.

-- 
gil

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

Re: IPCS formatting of I/O control blocks

[Binyamin Dissen]

On Thu, 27 Apr 2023 12:28:18 + Seymour J Metz  wrote:

:>The last time I looked, IPCS did not format, e.g., DCB, DECB, IOB. Has that 
changed?

Doesn't appear so. Need to make the formatting blocks.

--
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: IPCS formatting of I/O control blocks

[Jim Mulder]

  Yes, Wayne Rhoten enhanced that a while back.  I don't remember
which release of z/OS, but I have gotten accustomed to seeing it 
in the output from the SUMMARY FORMAT subcommand.

Jim Mulder  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, April 27, 2023 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IPCS formatting of I/O control blocks

The last time I looked, IPCS did not format, e.g., DCB, DECB, IOB. Has that 
changed?



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

[Michael Oujesky]

Presuming the program is assembler, I would suggest trying 
hard-coding for RECFM=VBS, LRECL=32767, BLKSIZE=32760, BFTEK=A.


And presuming all the files are RECFM=VBS.

If you do your own segmented record, LRECL=X ought to work.

Michael

At 08:00 AM 4/26/2023, Pierre Fichaud wrote:


Seymour's response made me realize that my post was incomplete.

I'm trying to read a concatenation of unlike data sets using QSAM.
The first dataset is VBS with LRECL=200,BLKSIZE=1000
The second dataset is VBS with LRECL=230,BLKSZIE= 1150.

I've coded a DCB OPEN exit that sets a re-read flag.
I had a SYNAD exit but removed it.
Prior to OPEN, I set the DCBOFPPC bit to 1.
After the OPEN, I set up the DCB OPEN exit.

I read the 1st data set and all is well.
When I attempt to read the 2nd data set, my DCB OPEN exit is driven.
It sets the re-read bit and then returns using R14.
I get control after the GET and test the re-read bit.
It is set so I do NOT process the record but go back to the GET.
I blow up with an S001-4. See below.
I was under the impression the technique described above prevents an 
S001 abend.
You could read through an entire concatenation without abending and 
with one OPEN.


Thanks in advance, Pierre.

   ..
08.40.17 JOB12309  +get1
08.40.17 JOB12309  +get1
08.40.17 JOB12309  +get1
08.40.17 JOB12309  +get1
08.40.17 JOB12309  +open exit
08.40.17 JOB12309  +reread1
08.40.17 JOB12309  IEC020I 001-4,TH127153,,FILEA-0002,0A97,MVSXXX,
08.40.17 JOB12309  IEC020I PIERRE.IN123456.VB230
08.40.17 JOB12309  IEC020I DCB EROPT=ABE OR AN INVALID CODE, AND/OR 
NO SYNAD EXIT SPECIFIED

08.40.20 JOB12309  IEA995I SYMPTOM DUMP OUTPUT  053
   053 SYSTEM COMPLETION CODE=001  REASON CODE=0004
   053  TIME=08.40.17  SEQ=05644  CPU=  ASID=001A
--
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: IPCS formatting of I/O control blocks

[Seymour J Metz]

I see TIOT (does that include XTIOT?) but not DCB, DECB or IOB, and I would 
have expected any new support for them to be via VERBEXIT.

Do you have a sample output? Thanks.


From: IBM Mainframe Discussion List  on behalf of Jim 
Mulder 
Sent: Thursday, April 27, 2023 2:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS formatting of I/O control blocks

  Yes, Wayne Rhoten enhanced that a while back.  I don't remember
which release of z/OS, but I have gotten accustomed to seeing it
in the output from the SUMMARY FORMAT subcommand.

Jim Mulder

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Thursday, April 27, 2023 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IPCS formatting of I/O control blocks

The last time I looked, IPCS did not format, e.g., DCB, DECB, IOB. Has that 
changed?



--
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: Inexplicable 0C4!

[Michael Stein]

On Thu, Apr 27, 2023 at 03:28:26PM +, Seymour J Metz wrote:
> Is it possible that the string is in key 0 or  read-only storage?

It's a certainty for the whole string, but probably not for the part
ending at the first x'00' byte.

TST  TRE   R2,R1  fold string
 
R0   R1   R2   R3PSW
 0009C5EC 1AA748F8 7FFF  078D04008009BD14

The string goes from the address in R2 for the length in R3:

So from 1AA748F8 for a length of 7FFF.

Now TRE will stop on the character in the low byte of R0 but can
get address exceptions for up to 4K beyond the matching byte.

So whats the protection status of the 4K block after the one pointed to by
R1, ie: 1AA748F8 -> 1AA75000

This 0C4 probably only happens when that next 4K block isn't storable...

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

Webinar on Different Approach to Certificate Problem Resolution

[Charles Mills]

Something of a plug; hit delete if you wish. X-Posted RACF-L and IBM-MAIN.

I have been reading and sometimes responding to various people’s “help me with 
my certificate problem” posts here for years. I have been kicking around 
various approaches to certificate problem resolution with my friend Paul 
Robichaux at NewEra. Most add-on certificate tools are what I would call 
“static” – they essentially front-end the various RACF commands and/or database 
and display certificate information in various more user-friendly formats, and 
front-end the RACF commands to make administration easier.

We got the idea of a “dynamic” approach: a tool that given a keyring and the 
address of a server would actually attempt a connection and tell you everything 
it learned doing that connection: all about the protocol and certificates if 
the connection succeeded; every detail of the failure if it failed. Among other 
features, it fully automates the production and formatting of the GSK trace. 
Just about every possible detail of the configuration is specifiable in a Web 
interface, and every detail of the session or attempted session is reported.

Anyway, I am going to do a Webinar and demo the tool this coming Tuesday. I 
will demo the resolution of two real-world certificate problems. Free. Minimal 
registration. No salesman will call you – I promise. Truly a demo, not a sales 
pitch. I would be honored if any of our associates here could attend.
https://events.r20.constantcontact.com/register/eventReg?oeidk=a07ejrm7u2yeb142c9b&oseq=&c=&ch=
 

Charles 

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

Re: Inexplicable 0C4!

[Seymour J Metz]

R1 is the table address; only 256 bytees need to be addressable. R2 is the 
string address, and you need write access to everything up until the delimiter 
('00'x in this case.)


From: IBM Mainframe Discussion List  on behalf of 
Michael Stein 
Sent: Thursday, April 27, 2023 3:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inexplicable 0C4!

On Thu, Apr 27, 2023 at 03:28:26PM +, Seymour J Metz wrote:
> Is it possible that the string is in key 0 or  read-only storage?

It's a certainty for the whole string, but probably not for the part
ending at the first x'00' byte.

TST  TRE   R2,R1  fold string

R0   R1   R2   R3PSW
 0009C5EC 1AA748F8 7FFF  078D04008009BD14

The string goes from the address in R2 for the length in R3:

So from 1AA748F8 for a length of 7FFF.

Now TRE will stop on the character in the low byte of R0 but can
get address exceptions for up to 4K beyond the matching byte.

So whats the protection status of the 4K block after the one pointed to by
R1, ie: 1AA748F8 -> 1AA75000

This 0C4 probably only happens when that next 4K block isn't storable...

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

How to call zEDC functions from an HLL other than C [was: RE: Unzip

[Tom Ross]

>I submitted an RCF on the subject of examples for actually using zEDC funct=
>ions from HLL's other than C not long after this message chain and received=
> no response at all from the RCF team.  A follow-up email requesting status=
> or at least an acknowledgement that the documentation addition suggestion =
>had been received did get a response, which was:

Peter,
  Sorry I did not see your post earlier!  I get the digest version of IBMMAIN
and search for COBOL to see if there is something I should comment on.
I am glad you were able to find my example of using zEDC from COBOL.
The zEDC team asked me to try it out from COBOL so I wrote a testcase to get
it working, then published it in our COBOL books. The zEDC team said that
they would put a pointet to COBOL books in the zEDC books,
I guess they did not do that (yet?)


Cheers,
TomR  >> COBOL is the Language of the Future! <<

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

Re: Inexplicable 0C4!

[Michael Stein]

On Thu, Apr 27, 2023 at 07:54:56PM +, Seymour J Metz wrote:
> R1 is the table address; only 256 bytees need to be addressable. R2
> is the string address, and you need write access to everything up until
> the delimiter ('00'x in this case.)

No!  You need write access for at least 4K from the start of the string even
if that's past the x'00'.

>From z/Architecture Priciples of Operation for the TRE instruction:

   Access exceptions for the portion of the first operand to the right
   of the last byte processed may or may not be recognized. For an
   operand longer than 4K bytes, access exceptions are not recognized
   for locations more than 4K bytes beyond the last byte processed.

His operand is 7fff long so it's longer than 4K so the at a minimum
he needs write access to the 4K where the string starts and the
next 4K too since the string doesn't start on a 4K boundary.

That's probably why his 0C4 only happens sometimes -- it depends
on the status/protect key of the next 4K block.

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

Re: Inexplicable 0C4!

[Seymour J Metz]

Yikes! 


From: IBM Mainframe Discussion List  on behalf of 
Michael Stein 
Sent: Thursday, April 27, 2023 5:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Inexplicable 0C4!

On Thu, Apr 27, 2023 at 07:54:56PM +, Seymour J Metz wrote:
> R1 is the table address; only 256 bytees need to be addressable. R2
> is the string address, and you need write access to everything up until
> the delimiter ('00'x in this case.)

No!  You need write access for at least 4K from the start of the string even
if that's past the x'00'.

>From z/Architecture Priciples of Operation for the TRE instruction:

   Access exceptions for the portion of the first operand to the right
   of the last byte processed may or may not be recognized. For an
   operand longer than 4K bytes, access exceptions are not recognized
   for locations more than 4K bytes beyond the last byte processed.

His operand is 7fff long so it's longer than 4K so the at a minimum
he needs write access to the 4K where the string starts and the
next 4K too since the string doesn't start on a 4K boundary.

That's probably why his 0C4 only happens sometimes -- it depends
on the status/protect key of the next 4K block.

--
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: Inexplicable 0C4!

[Tom Marchant]

IMO R3 should be set to a length that reflects the end of the storage 
containing the string.
Setting the length to 2 GB-1 is sloppy programming.

-- 
Tom Marchant

On Thu, 27 Apr 2023 14:09:17 -0700, Michael Stein  wrote:

>On Thu, Apr 27, 2023 at 07:54:56PM +, Seymour J Metz wrote:
>> R1 is the table address; only 256 bytees need to be addressable. R2
>> is the string address, and you need write access to everything up until
>> the delimiter ('00'x in this case.)
>
>No!  You need write access for at least 4K from the start of the string even
>if that's past the x'00'.
>
>From z/Architecture Priciples of Operation for the TRE instruction:
>
>   Access exceptions for the portion of the first operand to the right
>   of the last byte processed may or may not be recognized. For an
>   operand longer than 4K bytes, access exceptions are not recognized
>   for locations more than 4K bytes beyond the last byte processed.
>
>His operand is 7fff long so it's longer than 4K so the at a minimum
>he needs write access to the 4K where the string starts and the
>next 4K too since the string doesn't start on a 4K boundary.
>
>That's probably why his 0C4 only happens sometimes -- it depends
>on the status/protect key of the next 4K block.

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

Re: Inexplicable 0C4!

[Tom Marchant]

On Thu, 27 Apr 2023 19:58:23 +0700, Robin Atwood  wrote:

>Notice R3 hasn't changed, so the abend happened on the very first byte.

You don't know that. As I read it, POO says that R2 and R3 are adjusted when 
the condition code is set. It does not say that they are changed with every 
byte translated.

-- 
Tom Marchant

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

Re: interfacing C with Rexx

[David Crayford]

On 26/4/23 21:27, Rick Troth wrote:
I suggest that you consider porting Regina to z/OS, which is highly 
portable and easy to do. I have personally done it and even have a 
patch file somewhere. Currently, it's compiled in ASCII mode, but it 
can also support EBCDIC with some modifications to the lex lexer and 
YACC parser. Keep in mind that z/OS REXX programming services are 
mainly designed for HLASM and not HLL's. The best way to achieve good 
performance is by creating a subcommand processor using CEEPIPI to 
set up a pre-initialized LE environment and writing simple HLASM glue 
code. Although I've done this before, it requires a lot of work and 
is quite tedious just to use REXX https://github.com/daveyc/RTK.



I did some glue code for CMS once or twice to call C from Rexx. The 
hardest part in that context (similar for MVS) is ensuring that LE is 
instantiated. (And CEEPIPI is one way to do that, evidently. Good 
suggestion.)

Calling Rexx from C or assembler (in CMS) is almost trivial.

I wonder if you could get your Regina fix into the collection at 
https://github.com/ZOSOpenTools/?


I'm not sure about that! That would obligate me to support it which I no 
intention of doing :) I only use REXX when I have to so I don't want to 
be stuck supporting a port I don't use.



In any case, your patch is interesting. I didn't see it under 
https://github.com/daveyc/. Do share!


I'll fork the repo and then push up my changes  on a zos branch and post 
here. I'm will be turning issues off!!


I have to say that Regina REXX is quite good compared to z/OS REXX. Of 
course, it doesn't have the TSO/ISPF integrations but it does come with 
a utilities library with extra features such as copying/sorting stem 
variables etc. It also ships with a "rxstack" daemon which can be used 
for IPC. There are also extensions for associated arrays which can be 
passed to functions unlike stem variables. It's 3x faster then z/OS 
REXX, although that doesn't surprise me! As you mentioned, it's dirt 
easy to extend with C so it would be trivial to write a package that 
supports MVS data set I/O similar to my pyzfile Python package or sorted 
sets, algorithms etc.



The project in this case is the message handler that I mentioned a few 
weeks ago: works like CMS 'XMITMSG'. It includes an 'xmitmsg' command, 
so could be called as a command, but seemed right to make it a 
function too.
I'll include the Regina interface on GitHub "soon". 


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

Auto: Re: interfacing C with Rexx

[Frederic Mancini]

Je suis absent le 28 avril 2023.

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

[Paul Gilmartin]

On Thu, 27 Apr 2023 13:54:18 -0500, Michael Oujesky wrote:

>Presuming the program is assembler, I would suggest trying
>hard-coding for RECFM=VBS, LRECL=32767, BLKSIZE=32760, BFTEK=A.
>
>And presuming all the files are RECFM=VBS.
> 
In fact, can't any mixture of RECFM=V, VB, and VBS be overriden to those 
specifications?

>If you do your own segmented record, LRECL=X ought to work.

-- 
gil

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

Re: IBM RCF Documentation email address?

[Roger Bolan]

RCF?  Email?  Do you mean the old "reader's comment form"?I use the
"site feedback" button on the web pages.  For example, see z/OS 2.5.0 - IBM
Documentation 
I always seem to get a timely response.  I haven't used the old email
address in years.

On Mon, Apr 24, 2023 at 9:31 AM Farley, Peter <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> Is there a different documentation error / omission address then this one
> for IBM manuals?
>
> mhvr...@us.ibm.com
>
> I sent one to that address on April 4 and have yet to receive any reply,
> not even an acknowledgement that the email was received.
>
> Peter
>
> 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