Re: Large block interface for VB

[Michael Stein]

On Mon, Mar 01, 2021 at 09:37:57PM -0500, Joseph Reichman wrote:
> For NCP do you have to have a counter of the number of reads you do
> till you do a check

Yes, but since you need a separate DECB for each read I'd create the
DECB's after open based on the NCP value.  And then the "availablity"
of a not in use DECB would control the number of outstanding READs.

I strongly suspect that a good BSAM implementation isn't going to be
faster than QSAM.  QSAM can queue reads for more than one block.

See the DCB keyword BUFNO (and JCL DD DCB subparm BUFNO).

PS: I'd suggest using GET Locate mode (MACRF=GL)

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

Re: Large block interface for VB

[Attila Fogarasi]

Described in detail in the DFSMS Using Datasets manual, see
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idad400/uoiowb.htm
Includes sample code

On Tue, Mar 2, 2021 at 1:38 PM Joseph Reichman 
wrote:

> For NCP do you have to have a counter of the number of reads you do till
> you do a check
>
>
> > On Mar 1, 2021, at 7:34 PM, Joseph Reichman 
> wrote:
> >
> > Thanks I’ll look Into it
> >
> >> On Mar 1, 2021, at 7:16 PM, Farley, Peter x23353 <
> 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> >>
> >> Joseph,
> >>
> >> Apologies, I mis-remembered what SMB can do.  SMB is available only for
> VSAM files, not for concatenated QSAM files.  BLSR is one of two options
> for many-buffered QSAM input.
> >>
> >> The other option is to use the regular DD parameters NCP=nn,BUFNO=nn
> (max of 99 for each one) that may or may not help with I/.O performance.  I
> have run some work with NCP=99,BUFNO=99 with some helpful effects, though
> not dramatic.
> >>
> >> To really take advantage of NCP/BUFNO you probably would need to code
> to juggle "NCP" different READ's at a time using BSAM and your own
> de-blocking subroutine.  Lots of bookkeeping to keep track of them all and
> only CHECK in the correct order.  Robust recovery from I/O errors in such
> code is also a thorny problem.  Solvable, but thorny.
> >>
> >> Peter
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> Behalf Of Farley, Peter x23353
> >> Sent: Monday, March 1, 2021 1:43 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Large block interface for VB
> >>
> >> EXTERNAL EMAIL
> >>
> >> You assume correctly, it does.  In my experience both BLSR and SMB will
> handle concatenations of any size without any issue.
> >>
> >> When using BLSR your primary DD (the one your program reads) is coded
> with he BLSR parameters and nothing else, that DD then points (via a BLSR
> parameter) to a second DD where you put your large concatenation.
> >>
> >> SMB is applied directly to your primary DD name, specify the SMB
> parameters on only the first of the concatenated DD's.
> >>
> >> Peter
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> Behalf Of Joseph Reichman
> >> Sent: Monday, March 1, 2021 1:36 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Large block interface for VB
> >>
> >> Thank you I’m doing searches for files so I have over 100 concatenated
> files does the access matters I mean I assume QSAM reads a block under the
> covers
> >>
> >>
> >>
>  On Mar 1, 2021, at 1:26 PM, Farley, Peter x23353 <
> 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> >>>
> >>> Joseph,
> >>>
> >>> I believe that LBI is only for tape inputs and outputs.  You can speed
> up your processing easier by using either the older BLSR buffering
> subsystem or better the newer SMB buffering system.  See the JCL reference
> manual for SMB parameters.
> >>>
> >>> Allocate as much REGION as your installation will allow (some
> installations limit the maximum any job without special authorization may
> use, even sometimes production jobs).
> >>>
> >>> Use BLSR or SMB to allocate as many buffers as will fit in the REGION
> size you can allocate.
> >>>
> >>> I have seen substantial decreases in run time using these techniques
> with very large sequential files.
> >>>
> >>> I would also recommend using at least software compression or better
> hardware compression (if your CPU has it) for your large sequential files.
> The CPU time used for compression and decompression will sometimes be
> offset by decreases in elapsed time due to reduced I/O burdens for the
> compressed data, especially if you have hardware compression available.
> >>>
> >>> HTH
> >>>
> >>> Peter
> >>>
> >>> -Original Message-
> >>> From: IBM Mainframe Discussion List  On
> >>> Behalf Of Joseph Reichman
> >>> Sent: Monday, March 1, 2021 1:14 PM
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: Large block interface for VB
> >>>
> >>> Who uses tape
> >>>
> >>> I went to bsam trying to speed up my application wonder if going to
> >>> bsam
> >>>
> >>> Does anything positive for me
> >>>
> >> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >>
> >> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
> >>
> >> It disk then documentation says the system only supports tape at
> this time is That true ?
> >>
>  Have you any reason to doubt it?
> 
>  I suspect it's a hardware limitation.
> 
> >>> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote:
> >>
> >> On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
> >>
> >>> I have 100 files concatenated that are normally processed by qsam
> >>> with a lrecl 31996 and blksize 32000
> >>>
> >>> Since processing takes a long time I was looking to speed things
> >>> up by specifying a blksize of 32 in the 

Re: Large block interface for VB

[Farley, Peter x23353]

As far as I can remember (it's been a *long* time since I did this kind of 
programming), you should not (perhaps cannot?) exceed the NCP number of READ's 
at the same time using the same DCB.  Your code would need to use the NCP value 
from the opened DCB to control how many READ's you may issue before you need a 
CHECK.

IIRC there is a default NCP value - perhaps 5? -- that also needs to be 
considered if no override is present in the JCL or the DCB.  As I said, it's 
been a long time since I went that deep, so please RTFM for yourself.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Monday, March 1, 2021 9:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB

For NCP do you have to have a counter of the number of reads you do till you do 
a check 


> On Mar 1, 2021, at 7:34 PM, Joseph Reichman  wrote:
> 
> Thanks I’ll look Into it
> 
>> On Mar 1, 2021, at 7:16 PM, Farley, Peter x23353 
>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> Joseph,
>> 
>> Apologies, I mis-remembered what SMB can do.  SMB is available only for VSAM 
>> files, not for concatenated QSAM files.  BLSR is one of two options for 
>> many-buffered QSAM input.
>> 
>> The other option is to use the regular DD parameters NCP=nn,BUFNO=nn (max of 
>> 99 for each one) that may or may not help with I/.O performance.  I have run 
>> some work with NCP=99,BUFNO=99 with some helpful effects, though not 
>> dramatic.
>> 
>> To really take advantage of NCP/BUFNO you probably would need to code to 
>> juggle "NCP" different READ's at a time using BSAM and your own de-blocking 
>> subroutine.  Lots of bookkeeping to keep track of them all and only CHECK in 
>> the correct order.  Robust recovery from I/O errors in such code is also a 
>> thorny problem.  Solvable, but thorny.
>> 
>> Peter
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Farley, Peter x23353
>> Sent: Monday, March 1, 2021 1:43 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Large block interface for VB
>> 
>> EXTERNAL EMAIL
>> 
>> You assume correctly, it does.  In my experience both BLSR and SMB will 
>> handle concatenations of any size without any issue.
>> 
>> When using BLSR your primary DD (the one your program reads) is coded with 
>> he BLSR parameters and nothing else, that DD then points (via a BLSR 
>> parameter) to a second DD where you put your large concatenation.
>> 
>> SMB is applied directly to your primary DD name, specify the SMB parameters 
>> on only the first of the concatenated DD's.
>> 
>> Peter
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Joseph Reichman
>> Sent: Monday, March 1, 2021 1:36 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Large block interface for VB
>> 
>> Thank you I’m doing searches for files so I have over 100 
>> concatenated files does the access matters I mean I assume QSAM reads 
>> a block under the covers
>> 
>> 
>> 
 On Mar 1, 2021, at 1:26 PM, Farley, Peter x23353 
 <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>>> Joseph,
>>> 
>>> I believe that LBI is only for tape inputs and outputs.  You can speed up 
>>> your processing easier by using either the older BLSR buffering subsystem 
>>> or better the newer SMB buffering system.  See the JCL reference manual for 
>>> SMB parameters.
>>> 
>>> Allocate as much REGION as your installation will allow (some installations 
>>> limit the maximum any job without special authorization may use, even 
>>> sometimes production jobs).
>>> 
>>> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size 
>>> you can allocate.
>>> 
>>> I have seen substantial decreases in run time using these techniques with 
>>> very large sequential files.
>>> 
>>> I would also recommend using at least software compression or better 
>>> hardware compression (if your CPU has it) for your large sequential files.  
>>> The CPU time used for compression and decompression will sometimes be 
>>> offset by decreases in elapsed time due to reduced I/O burdens for the 
>>> compressed data, especially if you have hardware compression available.
>>> 
>>> HTH
>>> 
>>> Peter
>>> 
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On 
>>> Behalf Of Joseph Reichman
>>> Sent: Monday, March 1, 2021 1:14 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Large block interface for VB
>>> 
>>> Who uses tape
>>> 
>>> I went to bsam trying to speed up my application wonder if going to 
>>> bsam
>>> 
>>> Does anything positive for me
>>> 
>> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin 
>> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
>> 
>> It disk then documentation says the system only supports tape at this 
>> time is That true ?
>> 
 Have you any reason to doubt 

Re: z/OS ssh git issue

[David Crayford]

Let me know when you post and I will reach out to the open source guys 
on our Slack channel.


On 2/03/2021 10:10 am, Lionel B Dyck wrote:

I tried that forum over a month ago - I will do so once again.

_
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Monday, March 1, 2021 8:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

Can post on the Rocket Software open source forum with all the details from 
this thread. I don't think it's a Git problem as ssh also has the issue which 
is not part of ported tools. The forum is well monitored and the open source 
tools team are very helpful.

I will give Vladimir Ein a heads up.

On 1/03/2021 9:00 pm, Lionel B Dyck wrote:

That is exactly what I have which is why this is baffling  ☹

__
___
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Jousma, David
Sent: Monday, March 1, 2021 6:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

I know you responded back with the TAG ENV vars.  Here are all of mine
that are set in GITENV.sh

# ASCII support environment values
export _BPXK_AUTOCVT='ON'
export _CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)"
export _TAG_REDIR_ERR=txt
export _TAG_REDIR_IN=txt
export _TAG_REDIR_OUT=txt



__
___
Dave Jousma
AVP | Director, Technology Engineering

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
Rapids, MI 49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Lionel B Dyck
Sent: Monday, March 1, 2021 6:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or
unexpected emails**

They are set.

_TAG_REDIR_IN=txt
_TAG_REDIR_OUT=txt
_TAG_REDIR_ERR=txt

Thanks for the suggestion.  Now you can see why we are baffled.

__
___
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of David Crayford
Sent: Sunday, February 28, 2021 6:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

Make sure you also have the following set:

export _TAG_REDIR_ERR=txt
export _TAG_REDIR_IN=txt
export _TAG_REDIR_OUT=txt


On 28/02/2021 10:45 pm, Lionel B Dyck wrote:

I have in the environment on this system and on the working systems.

_BPXK_AUTOCVT=ON
_CEE_RUNOPTS=FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)

And I'm not sure which files you are asking about being tagged?

My ssh keys are untagged if that is your question - the same as on my working 
system.

_
_
___
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Michael Babcock
Sent: Saturday, February 27, 2021 8:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

Is AUTOCONVERT turned on in USS?  And the files are tagged?

On Sat, Feb 27, 2021 at 2:24 PM Lionel B Dyck  wrote:


I’m having an issue on a test lpar with git for z/OS – both version
2.14 and the latest 2.26 ports.



I’ve looked at this as have several others without success.



When I attempt a git clone I get this error:



fatal: protocol error: bad line length character: ---Á



When I do a ssh g...@github.com 
git-receive-pack lbdyck/qtab.git I get this:




--ÄÁ---Ä--ÃÃ-À--ÄÂÂ--Á-/ÄÁ---À/--ÊÁÃËÇÁ/ÀË_/ËÈÁÊÊÁø?ÊÈ-Ë
È / ÈÍË-ÊÁ ø?ÊÈ-ËÈ/ÈÍË-Î--ÀÁ%ÁÈÁ-ÊÁÃË-ËÑÀÁ-Â/>À---,-ÉÍÑÁÈ-/È?_ÑÄ-?Ã

Ë-ÀÁ%È/-øÍËÇ-?øÈÑ?>Ë-?¦ÁÄÈ-Ã?Ê_/È-ËÇ/--/ÅÁ>È-ÅÑÈÅÑÈÇÍÂ-Å-ÃÃ-Ä/À
-
-





If I do the same ssh g...@github.com 
git-receive-pack lbdyck/qtab.git on one of my other systems it looks
like
this:



00ce342c27f0363f6d24cbb68e8ace7454218d4828a2
refs/heads/masterreport-status
report-status-v2 delete-refs side-band-64k quiet atomic

ofs-delta push-options object-format=sha1

Re: Large block interface for VB

[Joseph Reichman]

For NCP do you have to have a counter of the number of reads you do till you do 
a check 


> On Mar 1, 2021, at 7:34 PM, Joseph Reichman  wrote:
> 
> Thanks I’ll look Into it 
> 
>> On Mar 1, 2021, at 7:16 PM, Farley, Peter x23353 
>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> Joseph,
>> 
>> Apologies, I mis-remembered what SMB can do.  SMB is available only for VSAM 
>> files, not for concatenated QSAM files.  BLSR is one of two options for 
>> many-buffered QSAM input.
>> 
>> The other option is to use the regular DD parameters NCP=nn,BUFNO=nn (max of 
>> 99 for each one) that may or may not help with I/.O performance.  I have run 
>> some work with NCP=99,BUFNO=99 with some helpful effects, though not 
>> dramatic.
>> 
>> To really take advantage of NCP/BUFNO you probably would need to code to 
>> juggle "NCP" different READ's at a time using BSAM and your own de-blocking 
>> subroutine.  Lots of bookkeeping to keep track of them all and only CHECK in 
>> the correct order.  Robust recovery from I/O errors in such code is also a 
>> thorny problem.  Solvable, but thorny.
>> 
>> Peter
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Farley, Peter x23353
>> Sent: Monday, March 1, 2021 1:43 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Large block interface for VB
>> 
>> EXTERNAL EMAIL
>> 
>> You assume correctly, it does.  In my experience both BLSR and SMB will 
>> handle concatenations of any size without any issue.
>> 
>> When using BLSR your primary DD (the one your program reads) is coded with 
>> he BLSR parameters and nothing else, that DD then points (via a BLSR 
>> parameter) to a second DD where you put your large concatenation.
>> 
>> SMB is applied directly to your primary DD name, specify the SMB parameters 
>> on only the first of the concatenated DD's.
>> 
>> Peter
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Joseph Reichman
>> Sent: Monday, March 1, 2021 1:36 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Large block interface for VB
>> 
>> Thank you I’m doing searches for files so I have over 100 concatenated files 
>> does the access matters I mean I assume QSAM reads a block under the covers 
>> 
>> 
>> 
 On Mar 1, 2021, at 1:26 PM, Farley, Peter x23353 
 <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>>> Joseph,
>>> 
>>> I believe that LBI is only for tape inputs and outputs.  You can speed up 
>>> your processing easier by using either the older BLSR buffering subsystem 
>>> or better the newer SMB buffering system.  See the JCL reference manual for 
>>> SMB parameters.
>>> 
>>> Allocate as much REGION as your installation will allow (some installations 
>>> limit the maximum any job without special authorization may use, even 
>>> sometimes production jobs).
>>> 
>>> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size 
>>> you can allocate.
>>> 
>>> I have seen substantial decreases in run time using these techniques with 
>>> very large sequential files.
>>> 
>>> I would also recommend using at least software compression or better 
>>> hardware compression (if your CPU has it) for your large sequential files.  
>>> The CPU time used for compression and decompression will sometimes be 
>>> offset by decreases in elapsed time due to reduced I/O burdens for the 
>>> compressed data, especially if you have hardware compression available.
>>> 
>>> HTH
>>> 
>>> Peter
>>> 
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On 
>>> Behalf Of Joseph Reichman
>>> Sent: Monday, March 1, 2021 1:14 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Large block interface for VB
>>> 
>>> Who uses tape
>>> 
>>> I went to bsam trying to speed up my application wonder if going to 
>>> bsam
>>> 
>>> Does anything positive for me
>>> 
>> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin 
>> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
>> 
>> It disk then documentation says the system only supports tape at this 
>> time is That true ?
>> 
 Have you any reason to doubt it?
 
 I suspect it's a hardware limitation.
 
>>> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote:
>> 
>> On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
>> 
>>> I have 100 files concatenated that are normally processed by qsam 
>>> with a lrecl 31996 and blksize 32000
>>> 
>>> Since processing takes a long time I was looking to speed things 
>>> up by specifying a blksize of 32 in the DCBE
>>> 
>> What device type?
>> 
>>> After the first read using bsam read macro I looked at the first 4 
>>> bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 
>>> which seemed to me that it was still processing blksize of 32,000
 
 -- gil
 
>> --

Re: IBM z/OS Management Facility 2021 Survey

[Erin Yu]

The z/OSMF survey will be extended two weeks to Mar. 14th. Welcome all your 
valuable feedback. Here is the 
link:https://www.surveygizmo.com/s3/6163579/IBM-z-OS-Management-Facility-2021-Survey.
 



Thanks & Best Regards

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

Re: z/OS ssh git issue

[Lionel B Dyck]

I tried that forum over a month ago - I will do so once again.

_
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Monday, March 1, 2021 8:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

Can post on the Rocket Software open source forum with all the details from 
this thread. I don't think it's a Git problem as ssh also has the issue which 
is not part of ported tools. The forum is well monitored and the open source 
tools team are very helpful.

I will give Vladimir Ein a heads up.

On 1/03/2021 9:00 pm, Lionel B Dyck wrote:
> That is exactly what I have which is why this is baffling  ☹
>
> __
> ___
> Lionel B Dyck <
> Website: www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is 
> what you are, reputation merely what others think you are." - John 
> Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Jousma, David
> Sent: Monday, March 1, 2021 6:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS ssh git issue
>
> I know you responded back with the TAG ENV vars.  Here are all of mine 
> that are set in GITENV.sh
>
> # ASCII support environment values
> export _BPXK_AUTOCVT='ON'
> export _CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)"
> export _TAG_REDIR_ERR=txt
> export _TAG_REDIR_IN=txt
> export _TAG_REDIR_OUT=txt
>
>
>
> __
> ___
> Dave Jousma
> AVP | Director, Technology Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand 
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Lionel B Dyck
> Sent: Monday, March 1, 2021 6:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS ssh git issue
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or 
> unexpected emails**
>
> They are set.
>
> _TAG_REDIR_IN=txt
> _TAG_REDIR_OUT=txt
> _TAG_REDIR_ERR=txt
>
> Thanks for the suggestion.  Now you can see why we are baffled.
>
> __
> ___
> Lionel B Dyck <
> Website: www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is 
> what you are, reputation merely what others think you are." - John 
> Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of David Crayford
> Sent: Sunday, February 28, 2021 6:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS ssh git issue
>
> Make sure you also have the following set:
>
> export _TAG_REDIR_ERR=txt
> export _TAG_REDIR_IN=txt
> export _TAG_REDIR_OUT=txt
>
>
> On 28/02/2021 10:45 pm, Lionel B Dyck wrote:
>> I have in the environment on this system and on the working systems.
>>
>> _BPXK_AUTOCVT=ON
>> _CEE_RUNOPTS=FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)
>>
>> And I'm not sure which files you are asking about being tagged?
>>
>> My ssh keys are untagged if that is your question - the same as on my 
>> working system.
>>
>> _
>> _
>> ___
>> Lionel B Dyck <
>> Website: www.lbdsoftware.com
>>
>> "Worry more about your character than your reputation.  Character is 
>> what you are, reputation merely what others think you are." - John 
>> Wooden
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Michael Babcock
>> Sent: Saturday, February 27, 2021 8:02 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: z/OS ssh git issue
>>
>> Is AUTOCONVERT turned on in USS?  And the files are tagged?
>>
>> On Sat, Feb 27, 2021 at 2:24 PM Lionel B Dyck  wrote:
>>
>>> I’m having an issue on a test lpar with git for z/OS – both version
>>> 2.14 and the latest 2.26 ports.
>>>
>>>
>>>
>>> I’ve looked at this as have several others without success.
>>>
>>>
>>>
>>> When I attempt a git clone I get this error:
>>>
>>>
>>>
>>> fatal: protocol error: bad line length character: ---Á
>>>
>>>
>>>
>>> When I do a ssh g...@github.com  
>>> git-receive-pack lbdyck/qtab.git I get this:
>>>
>>>
>>>
>>>
>>> --ÄÁ---Ä--ÃÃ-À--ÄÂÂ--Á-/ÄÁ---À/--ÊÁÃËÇÁ/ÀË_/ËÈÁÊÊÁø?ÊÈ-Ë
>>> È / ÈÍË-ÊÁ ø?ÊÈ-ËÈ/ÈÍË-Î--ÀÁ%ÁÈÁ-ÊÁÃË-ËÑÀÁ-Â/>À---,-ÉÍÑÁÈ-/È?_ÑÄ-?Ã
>>>
>>> Ë-ÀÁ%È/-øÍËÇ-?øÈÑ?>Ë-?¦ÁÄÈ-Ã?Ê_/È-ËÇ/--/ÅÁ>È-ÅÑÈÅÑÈÇÍÂ-Å-ÃÃ-Ä/À
>>> -
>>> -
>>> 
>>>
>>>
>>>
>>>
>>> If I do the same ssh g...@github.com  
>>> git-receive-pack lbdyck/qtab.git on one of my other 

Re: z/OS ssh git issue

[David Crayford]

Can post on the Rocket Software open source forum with all the details 
from this thread. I don't think it's a Git problem as ssh also has the 
issue which is not part of ported tools. The forum is well monitored and 
the open source tools team are very helpful.


I will give Vladimir Ein a heads up.

On 1/03/2021 9:00 pm, Lionel B Dyck wrote:

That is exactly what I have which is why this is baffling  ☹

_
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Monday, March 1, 2021 6:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

I know you responded back with the TAG ENV vars.  Here are all of mine that are 
set in GITENV.sh

# ASCII support environment values
export _BPXK_AUTOCVT='ON'
export _CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)"
export _TAG_REDIR_ERR=txt
export _TAG_REDIR_IN=txt
export _TAG_REDIR_OUT=txt



_
Dave Jousma
AVP | Director, Technology Engineering

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B Dyck
Sent: Monday, March 1, 2021 6:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

They are set.

_TAG_REDIR_IN=txt
_TAG_REDIR_OUT=txt
_TAG_REDIR_ERR=txt

Thanks for the suggestion.  Now you can see why we are baffled.

_
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Sunday, February 28, 2021 6:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

Make sure you also have the following set:

export _TAG_REDIR_ERR=txt
export _TAG_REDIR_IN=txt
export _TAG_REDIR_OUT=txt


On 28/02/2021 10:45 pm, Lionel B Dyck wrote:

I have in the environment on this system and on the working systems.

_BPXK_AUTOCVT=ON
_CEE_RUNOPTS=FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)

And I'm not sure which files you are asking about being tagged?

My ssh keys are untagged if that is your question - the same as on my working 
system.

__
___
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Michael Babcock
Sent: Saturday, February 27, 2021 8:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

Is AUTOCONVERT turned on in USS?  And the files are tagged?

On Sat, Feb 27, 2021 at 2:24 PM Lionel B Dyck  wrote:


I’m having an issue on a test lpar with git for z/OS – both version
2.14 and the latest 2.26 ports.



I’ve looked at this as have several others without success.



When I attempt a git clone I get this error:



fatal: protocol error: bad line length character: ---Á



When I do a ssh g...@github.com 
git-receive-pack lbdyck/qtab.git I get this:




--ÄÁ---Ä--ÃÃ-À--ÄÂÂ--Á-/ÄÁ---À/--ÊÁÃËÇÁ/ÀË_/ËÈÁÊÊÁø?ÊÈ-ËÈ
/ ÈÍË-ÊÁ ø?ÊÈ-ËÈ/ÈÍË-Î--ÀÁ%ÁÈÁ-ÊÁÃË-ËÑÀÁ-Â/>À---,-ÉÍÑÁÈ-/È?_ÑÄ-?Ã

Ë-ÀÁ%È/-øÍËÇ-?øÈÑ?>Ë-?¦ÁÄÈ-Ã?Ê_/È-ËÇ/--/ÅÁ>È-ÅÑÈÅÑÈÇÍÂ-Å-ÃÃ-Ä/À-
-





If I do the same ssh g...@github.com 
git-receive-pack lbdyck/qtab.git on one of my other systems it looks
like
this:



00ce342c27f0363f6d24cbb68e8ace7454218d4828a2
refs/heads/masterreport-status
report-status-v2 delete-refs side-band-64k quiet atomic

ofs-delta push-options object-format=sha1
agent=git/github-g2ff1cad44179




We’ve looked at the TCP/IP setup, the SSH setup, and the Git setup
with no joy.  We’ve also confirmed that the ssh public key has been
properly added to github.



Can anyone provide any suggestions that will help resolve this?



Thank you





­­­__
_
__


Lionel B Dyck <

Website:   www.lbdsoftware.com



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




-
- 

Re: FTP-SSL from z/OS client to Linux

[John S. Giltner, Jr.]

I've always just did:

gskstrace gsktrace.trc > gsktrace.txt

But I do generally use the gsktrace to try and figure out issues with ssl 
negotiation.

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

Re: Large block interface for VB

[Joseph Reichman]

Thanks I’ll look Into it 

> On Mar 1, 2021, at 7:16 PM, Farley, Peter x23353 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Joseph,
> 
> Apologies, I mis-remembered what SMB can do.  SMB is available only for VSAM 
> files, not for concatenated QSAM files.  BLSR is one of two options for 
> many-buffered QSAM input.
> 
> The other option is to use the regular DD parameters NCP=nn,BUFNO=nn (max of 
> 99 for each one) that may or may not help with I/.O performance.  I have run 
> some work with NCP=99,BUFNO=99 with some helpful effects, though not dramatic.
> 
> To really take advantage of NCP/BUFNO you probably would need to code to 
> juggle "NCP" different READ's at a time using BSAM and your own de-blocking 
> subroutine.  Lots of bookkeeping to keep track of them all and only CHECK in 
> the correct order.  Robust recovery from I/O errors in such code is also a 
> thorny problem.  Solvable, but thorny.
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Farley, Peter x23353
> Sent: Monday, March 1, 2021 1:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Large block interface for VB
> 
> EXTERNAL EMAIL
> 
> You assume correctly, it does.  In my experience both BLSR and SMB will 
> handle concatenations of any size without any issue.
> 
> When using BLSR your primary DD (the one your program reads) is coded with he 
> BLSR parameters and nothing else, that DD then points (via a BLSR parameter) 
> to a second DD where you put your large concatenation.
> 
> SMB is applied directly to your primary DD name, specify the SMB parameters 
> on only the first of the concatenated DD's.
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Joseph Reichman
> Sent: Monday, March 1, 2021 1:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Large block interface for VB
> 
> Thank you I’m doing searches for files so I have over 100 concatenated files 
> does the access matters I mean I assume QSAM reads a block under the covers 
> 
> 
> 
>> On Mar 1, 2021, at 1:26 PM, Farley, Peter x23353 
>> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> Joseph,
>> 
>> I believe that LBI is only for tape inputs and outputs.  You can speed up 
>> your processing easier by using either the older BLSR buffering subsystem or 
>> better the newer SMB buffering system.  See the JCL reference manual for SMB 
>> parameters.
>> 
>> Allocate as much REGION as your installation will allow (some installations 
>> limit the maximum any job without special authorization may use, even 
>> sometimes production jobs).
>> 
>> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size 
>> you can allocate.
>> 
>> I have seen substantial decreases in run time using these techniques with 
>> very large sequential files.
>> 
>> I would also recommend using at least software compression or better 
>> hardware compression (if your CPU has it) for your large sequential files.  
>> The CPU time used for compression and decompression will sometimes be offset 
>> by decreases in elapsed time due to reduced I/O burdens for the compressed 
>> data, especially if you have hardware compression available.
>> 
>> HTH
>> 
>> Peter
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On 
>> Behalf Of Joseph Reichman
>> Sent: Monday, March 1, 2021 1:14 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Large block interface for VB
>> 
>> Who uses tape
>> 
>> I went to bsam trying to speed up my application wonder if going to 
>> bsam
>> 
>> Does anything positive for me
>> 
> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
> 
> It disk then documentation says the system only supports tape at this 
> time is That true ?
> 
>>> Have you any reason to doubt it?
>>> 
>>> I suspect it's a hardware limitation.
>>> 
>> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote:
> 
> On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
> 
>> I have 100 files concatenated that are normally processed by qsam 
>> with a lrecl 31996 and blksize 32000
>> 
>> Since processing takes a long time I was looking to speed things 
>> up by specifying a blksize of 32 in the DCBE
>> 
> What device type?
> 
>> After the first read using bsam read macro I looked at the first 4 
>> bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 
>> which seemed to me that it was still processing blksize of 32,000
>>> 
>>> -- gil
>>> 
> --
> 
> 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 

Re: FTP-SSL from z/OS client to Linux

[Frank Swarbrick]

It looks to me like "550 T" is the start of the FTP message type 550, Requested 
action not taken.
Doesn't seem like something the server should be sending in the middle of a 
CLIENT-HELLO negotiation.  But I'm no expert.

Is it safe to assume that non-z/OS clients are successfully connecting to this 
server?


From: IBM Mainframe Discussion List  on behalf of 
John S. Giltner, Jr. 
Sent: Monday, March 1, 2021 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP-SSL from z/OS client to Linux

Well in the data you sent out on the client hello I only see two x'35', on is 
at byte 3,which is part of the length field.  The other is at 2C which really 
starts at 2B which is cipher x'0035'

In your 1st post the trace showed part of a error message that I think you were 
receiving which as "550 T".  Were you receiving that message and if so what was 
the full message.

You know it just hit me that "5" in HEX (ASCII) is x'35'.  Maybe the client is 
sending the error message that starts "550 T" and your side it interpreting 
that error message as part of the TLS negotiation and it has no idea what a 
x'35' is.

--
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: FTP with TLSv1.2 and SHA256

[Frank Swarbrick]

Thanks for confirming.


From: IBM Mainframe Discussion List  on behalf of 
John S. Giltner, Jr. 
Sent: Sunday, February 28, 2021 2:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP with TLSv1.2 and SHA256

That is what I opened the PMR for and IBM said that  FTP does not pass 
GSK_V3_CIPHER_SPECS_EXPANDED to System SSL.  To get any of the 4 character 
ciphers you must use AT-TLS.

--
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: Large block interface for VB

[Farley, Peter x23353]

Joseph,

Apologies, I mis-remembered what SMB can do.  SMB is available only for VSAM 
files, not for concatenated QSAM files.  BLSR is one of two options for 
many-buffered QSAM input.

The other option is to use the regular DD parameters NCP=nn,BUFNO=nn (max of 99 
for each one) that may or may not help with I/.O performance.  I have run some 
work with NCP=99,BUFNO=99 with some helpful effects, though not dramatic.

To really take advantage of NCP/BUFNO you probably would need to code to juggle 
"NCP" different READ's at a time using BSAM and your own de-blocking 
subroutine.  Lots of bookkeeping to keep track of them all and only CHECK in 
the correct order.  Robust recovery from I/O errors in such code is also a 
thorny problem.  Solvable, but thorny.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter x23353
Sent: Monday, March 1, 2021 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB

EXTERNAL EMAIL

You assume correctly, it does.  In my experience both BLSR and SMB will handle 
concatenations of any size without any issue.

When using BLSR your primary DD (the one your program reads) is coded with he 
BLSR parameters and nothing else, that DD then points (via a BLSR parameter) to 
a second DD where you put your large concatenation.

SMB is applied directly to your primary DD name, specify the SMB parameters on 
only the first of the concatenated DD's.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Monday, March 1, 2021 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB

Thank you I’m doing searches for files so I have over 100 concatenated files 
does the access matters I mean I assume QSAM reads a block under the covers 



> On Mar 1, 2021, at 1:26 PM, Farley, Peter x23353 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Joseph,
> 
> I believe that LBI is only for tape inputs and outputs.  You can speed up 
> your processing easier by using either the older BLSR buffering subsystem or 
> better the newer SMB buffering system.  See the JCL reference manual for SMB 
> parameters.
> 
> Allocate as much REGION as your installation will allow (some installations 
> limit the maximum any job without special authorization may use, even 
> sometimes production jobs).
> 
> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size 
> you can allocate.
> 
> I have seen substantial decreases in run time using these techniques with 
> very large sequential files.
> 
> I would also recommend using at least software compression or better hardware 
> compression (if your CPU has it) for your large sequential files.  The CPU 
> time used for compression and decompression will sometimes be offset by 
> decreases in elapsed time due to reduced I/O burdens for the compressed data, 
> especially if you have hardware compression available.
> 
> HTH
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Joseph Reichman
> Sent: Monday, March 1, 2021 1:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Large block interface for VB
> 
> Who uses tape
> 
> I went to bsam trying to speed up my application wonder if going to 
> bsam
> 
> Does anything positive for me
> 
>>> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin 
>>> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>>> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
>>> 
>>> It disk then documentation says the system only supports tape at this time 
>>> is That true ?
>>> 
>> Have you any reason to doubt it?
>> 
>> I suspect it's a hardware limitation.
>> 
> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote:
 
 On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
 
> I have 100 files concatenated that are normally processed by qsam 
> with a lrecl 31996 and blksize 32000
> 
> Since processing takes a long time I was looking to speed things 
> up by specifying a blksize of 32 in the DCBE
> 
 What device type?
 
> After the first read using bsam read macro I looked at the first 4 
> bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 
> which seemed to me that it was still processing blksize of 32,000
>> 
>> -- gil
>> 
--

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 / 

Re: FTP-SSL from z/OS client to Linux

[John S. Giltner, Jr.]

Well in the data you sent out on the client hello I only see two x'35', on is 
at byte 3,which is part of the length field.  The other is at 2C which really 
starts at 2B which is cipher x'0035'

In your 1st post the trace showed part of a error message that I think you were 
receiving which as "550 T".  Were you receiving that message and if so what was 
the full message.

You know it just hit me that "5" in HEX (ASCII) is x'35'.  Maybe the client is 
sending the error message that starts "550 T" and your side it interpreting 
that error message as part of the TLS negotiation and it has no idea what a 
x'35' is.

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

Re: BLS18160D Response

[Jim Mulder]

  For example, VERBX VSMDATA traverses data structures which are 
not serialized while they are being captured by 
IEATDUMP/SYSMDUMP/SDUMP.  As a result, sometimes the 
VSMDATA processing encounters problems due to inconsistent
data structures in the dump.  The potential for inconsistencies can be
exacerbated when some register at time of error or SUMLST range 
causes some of the relevant VSM stuff  data to be captured 
early during disabled or suspend summary dump, and the rest
captured later.  So when you see VSMDATA spewing error 
messages, sometimes you say, "Let me try dropping the dump
and reinitializing it, replying N to BLS18160D, and then see if 
VSMDATA works better for this dump". 

  Replying N to BLS18160D is something I do only
rarely, but there are times when, in order to understand what
is going on in a dump, you need to know a considerable
amount  about how dumping works. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on 
02/27/2021 09:03:17 PM:

> From: "Ed Jaffe" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 03/01/2021 05:04 PM
> Subject: BLS18160D Response
> Sent by: "IBM Mainframe Discussion List" 
> 
> Regarding:
> 
> "BLS18160D May summary dump data be used by dump access?  Enter Y to 
> use, N to bypass."
> 
> Under what conditions would it ever be appropriate to reply N?



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

Re: BLS18160D Response

[Jim Mulder]

  That doc is about 20 years out of date.  Prior to z/OS 1.2, summary
 dump could capture multiple SUMDUMP ranges in a single 
self-describing 4K dump record, and the metadata for the ranges 
did not include the storage key.  When 64-bit virtual storage was 
implemented in z/OS 1.2, we decided not to to  extend
this methodology to 64-bit addresses, and instead, round 
SUMPDUMP ranges down and up to 4K page boundaries. 
Having done that, all of the storage in a SUMDUMP record 
is now the same key, so we capture its key into the record 
header, like we do for any other storage being dumped. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


"IBM Mainframe Discussion List"  wrote on 
02/28/2021 11:08:55 AM:

> From: "Ed Jaffe" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 03/01/2021 04:09 PM
> Subject: Re: BLS18160D Response
> Sent by: "IBM Mainframe Discussion List" 
> 
> On 2/27/2021 7:48 PM, Mark Jacobs wrote:
> > >From the FM;
> >
> > The summary dump data contains data captured closest to the time 
> of the failure. If you reply Y to use this data, IPCS will not be 
> able to display storage keys using the DISPLAY(MACHINE) parameter.
> 
> Yeah, but...
> 
> I don't experience issues displaying keys using DISPLAY(MACHINE) when 
> responding 'Y' to BLS18160D.
> 
> I tried it just now. I initialized a dump still lying around from 
> yesterday (SLIP to capture an SDC2 abend in an SRB) and responded 'Y' to 

> the BLS18160D prompt:
> 
>   IKJ56650I TIME-07:42:42 AM. CPU-00:00:03 SERVICE-22127 
> SESSION-00:00:47 FEBRUARY 28,2021
>   BLS18122I Initialization in progress for 
> DSNAME('SYS3.DUMP.D210227.T222342.EDJX2.S8')
>   BLS18124I TITLE=SLIP DUMP ID=EEJ6
>   BLS18223I Dump written by z/OS 02.04.00-0 SLIP - level same as IPCS 
level
>   BLS18558I This redactable dump has not been post-processed to protect 
> sensitive data
>   BLS18222I z/Architecture mode system
>   BLS18160D May summary dump data be used by dump access?  Enter Y to 
> use, N to bypass.
> y
>   BLS18255I Dump InitElapsed Time  CPU Time
> Input I/O   00:00:01.205379 00:00:01.041953
> DDIR00:00:00.842453 00:00:00.605543
>   BLS18123I 161,077 blocks, 670,080,320 bytes, in 
> DSNAME('SYS3.DUMP.D210227.T222342.EDJX2.S8')
>   IKJ56650I TIME-07:44:17 AM. CPU-00:00:07 SERVICE-42085 
> SESSION-00:02:21 FEBRUARY 28,2021
>   BLS18224I Dump of z/OS 02.04.00-0 - level same as IPCS level
>   ***
> 
> STATUS shows PSW and registers for the DC2 abend:
> 
> CPU STATUS:
> PSW=47045000 8000  019A7318
>  (Running in AR, key 0, AMODE 31, DAT ON, SUPERVISOR STATE)
>  Enabled for PER I/O EXT MCH
> ASID(X'0072') 019A7318. IEANUC01.IAXV6+24D0 IN READ ONLY NUCLEUS
>ASCB114 at FBD400, JOB(EDJX2), for the home ASID
>ASXB114 at AFD000 for the home ASID. No block is dispatched
>HOME ASID: 0072 PRIMARY ASID: 0072 SECONDARY ASID: 0072
> 
>General purpose register values
>  Left halves of all registers contain zeros
>   0-3  8400  84DC2000  0001  
>   4-7    029B9000  00FBD400  01DDDF00
>   8-11   042FCC30    08004000
>  12-15 019A8550  042FE178  042FE000  66004020
> 
> SUMDUMP captures storage on both sides of the PSW and every register. I 
> have 'IP SETDEF DISPLAY(MACHINE)' in effect. Listing the PSW via 'IP L 
> 019A7318' returns KEY(08):
> 
> LIST 019A7318. ASID(X'0072') LENGTH(X'2000') AREA
> ASID(X'0072') ADDRESS(019A7318.) KEY(00)
> 019A7318. B24D001C E31D 00045811 00889110 |.(..Thj.|
> 019A7328. 1008A784 0009C019 04C0D000 C0F9FE00 |..xd..{..{}.{9..|
> 
> 'IP L 5R!' returns KEY(00):
> 
> LIST 029B9000. ASID(X'0072') LENGTH(X'2000') AREA
> ASID(X'0072') ADDRESS(029B9000.) KEY(08)
> 029B9000. C9C1E7C3 D7E3C2D3 0012  |IAXCPTBL|
> 029B9010. 0012 0040 042FC000  |... ..{.|
> 
> 'IP L 7R!' returns KEY(00):
> 
> LIST 01DDDF00. ASID(X'0072') LENGTH(X'2000') AREA
> ASID(X'0072') ADDRESS(01DDDF00.) KEY(00)
> 01DDDF00. D9C3C540 002E65A3 0FFE 0EB6 |RCE ...t|
> 01DDDF10. 050B 00350202 142E 28C0 |...{|
> 
> 'IP L 9R!' returns KEY(00):
> 
> LIST 042FCC30. ASID(X'0072') LENGTH(X'2000') AREA
> ASID(X'0072') ADDRESS(042FCC30.) KEY(00)
> 042FCC30.  009A   ||
> 042FCC40.  042FC000  042FC004 |..{...{.|
> 
> Same with all of the other registers that look like addresses. Not one 
> does not show the KEY information. I get similar results when processing 

> dumps in TCB mode. Pretty much everything pointed to by the RTM2WA is 
> included in the SUMDUMP and KEY information seems to be routinely 
provided.
> 
> Perhaps there is some pathological situation where that information 
> doesn't display?
> 
> -- 
> 
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
> 

Re: BLS18160D Response

[Jim Mulder]

  RSMDATA shows you what z/OS intends for the key to be.
DISPLAY  shows you what the key actually is, via IVSK for
IEATDUMP/SYSMDUMP/SDUMP and ISKE for SADMP.

 Other than DAT table overlays or some supervisor state 
doofus thinking it is ok for something other than RSM 
to use the SSKE instruction, those things are in agreement. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

"IBM Mainframe Discussion List"  wrote on 
03/01/2021 04:26:52 AM:

> From: "Barbara Nitz" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 03/01/2021 04:12 PM
> Subject: Re: BLS18160D Response
> Sent by: "IBM Mainframe Discussion List" 
> 
> On Sun, 28 Feb 2021 08:08:55 -0800, Ed Jaffe 
>  wrote:
> 
> >I don't experience issues displaying keys using DISPLAY(MACHINE) when
> >responding 'Y' to BLS18160D.
> 
> Did you compare the keys with what rsmdata knows about the key of 
> the page? I learned to use 'yes' to the BLS message and only to use 
> the key for the page that rsmdata shows.



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

Re: Large block interface for VB

[Farley, Peter x23353]

You assume correctly, it does.  In my experience both BLSR and SMB will handle 
concatenations of any size without any issue.

When using BLSR your primary DD (the one your program reads) is coded with he 
BLSR parameters and nothing else, that DD then points (via a BLSR parameter) to 
a second DD where you put your large concatenation.

SMB is applied directly to your primary DD name, specify the SMB parameters on 
only the first of the concatenated DD's.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Monday, March 1, 2021 1:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB

Thank you I’m doing searches for files so I have over 100 concatenated files 
does the access matters I mean I assume QSAM reads a block under the covers 



> On Mar 1, 2021, at 1:26 PM, Farley, Peter x23353 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Joseph,
> 
> I believe that LBI is only for tape inputs and outputs.  You can speed up 
> your processing easier by using either the older BLSR buffering subsystem or 
> better the newer SMB buffering system.  See the JCL reference manual for SMB 
> parameters.
> 
> Allocate as much REGION as your installation will allow (some installations 
> limit the maximum any job without special authorization may use, even 
> sometimes production jobs).
> 
> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size 
> you can allocate.
> 
> I have seen substantial decreases in run time using these techniques with 
> very large sequential files.
> 
> I would also recommend using at least software compression or better hardware 
> compression (if your CPU has it) for your large sequential files.  The CPU 
> time used for compression and decompression will sometimes be offset by 
> decreases in elapsed time due to reduced I/O burdens for the compressed data, 
> especially if you have hardware compression available.
> 
> HTH
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Joseph Reichman
> Sent: Monday, March 1, 2021 1:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Large block interface for VB
> 
> Who uses tape
> 
> I went to bsam trying to speed up my application wonder if going to 
> bsam
> 
> Does anything positive for me
> 
>>> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin 
>>> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>>> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
>>> 
>>> It disk then documentation says the system only supports tape at this time 
>>> is That true ?
>>> 
>> Have you any reason to doubt it?
>> 
>> I suspect it's a hardware limitation.
>> 
> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote:
 
 On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
 
> I have 100 files concatenated that are normally processed by qsam 
> with a lrecl 31996 and blksize 32000
> 
> Since processing takes a long time I was looking to speed things 
> up by specifying a blksize of 32 in the DCBE
> 
 What device type?
 
> After the first read using bsam read macro I looked at the first 4 
> bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 
> which seemed to me that it was still processing blksize of 32,000
>> 
>> -- gil
>> 
--

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

Re: Large block interface for VB

[Joseph Reichman]

Thank you I’m doing searches for files so I have over 100 concatenated files 
does the access matters I mean I assume QSAM reads a block under the covers 



> On Mar 1, 2021, at 1:26 PM, Farley, Peter x23353 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Joseph,
> 
> I believe that LBI is only for tape inputs and outputs.  You can speed up 
> your processing easier by using either the older BLSR buffering subsystem or 
> better the newer SMB buffering system.  See the JCL reference manual for SMB 
> parameters.
> 
> Allocate as much REGION as your installation will allow (some installations 
> limit the maximum any job without special authorization may use, even 
> sometimes production jobs).
> 
> Use BLSR or SMB to allocate as many buffers as will fit in the REGION size 
> you can allocate.
> 
> I have seen substantial decreases in run time using these techniques with 
> very large sequential files.
> 
> I would also recommend using at least software compression or better hardware 
> compression (if your CPU has it) for your large sequential files.  The CPU 
> time used for compression and decompression will sometimes be offset by 
> decreases in elapsed time due to reduced I/O burdens for the compressed data, 
> especially if you have hardware compression available.
> 
> HTH
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Joseph Reichman
> Sent: Monday, March 1, 2021 1:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Large block interface for VB
> 
> EXTERNAL EMAIL
> 
> Who uses tape 
> 
> I went to bsam trying to speed up my application wonder if going to bsam 
> 
> Does anything positive for me 
> 
>>> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin 
>>> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>> 
>>> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
>>> 
>>> It disk then documentation says the system only supports tape at this time 
>>> is That true ?
>>> 
>> Have you any reason to doubt it?
>> 
>> I suspect it's a hardware limitation.
>> 
> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote:
 
 On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
 
> I have 100 files concatenated that are normally processed by qsam 
> with a lrecl 31996 and blksize 32000
> 
> Since processing takes a long time I was looking to speed things up 
> by specifying a blksize of 32 in the DCBE
> 
 What device type?
 
> After the first read using bsam read macro I looked at the first 4 
> bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 
> which seemed to me that it was still processing blksize of 32,000
>> 
>> -- 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
> 
> 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: Large block interface for VB

[Farley, Peter x23353]

Joseph,

I believe that LBI is only for tape inputs and outputs.  You can speed up your 
processing easier by using either the older BLSR buffering subsystem or better 
the newer SMB buffering system.  See the JCL reference manual for SMB 
parameters.

Allocate as much REGION as your installation will allow (some installations 
limit the maximum any job without special authorization may use, even sometimes 
production jobs).

Use BLSR or SMB to allocate as many buffers as will fit in the REGION size you 
can allocate.

I have seen substantial decreases in run time using these techniques with very 
large sequential files.

I would also recommend using at least software compression or better hardware 
compression (if your CPU has it) for your large sequential files.  The CPU time 
used for compression and decompression will sometimes be offset by decreases in 
elapsed time due to reduced I/O burdens for the compressed data, especially if 
you have hardware compression available.

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Monday, March 1, 2021 1:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Large block interface for VB

EXTERNAL EMAIL

Who uses tape 

I went to bsam trying to speed up my application wonder if going to bsam 

Does anything positive for me 

> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
> 
>> It disk then documentation says the system only supports tape at this time 
>> is That true ?
>> 
> Have you any reason to doubt it?
> 
> I suspect it's a hardware limitation.
> 
 On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote:
>>> 
>>> On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
>>> 
 I have 100 files concatenated that are normally processed by qsam 
 with a lrecl 31996 and blksize 32000
 
 Since processing takes a long time I was looking to speed things up 
 by specifying a blksize of 32 in the DCBE
 
>>> What device type?
>>> 
 After the first read using bsam read macro I looked at the first 4 
 bytes ( Block descriptor word ) and it was x’7C4A’ which is 31,888 
 which seemed to me that it was still processing blksize of 32,000
> 
> -- 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

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

Re: Large block interface for VB

[Paul Gilmartin]

On Mon, 1 Mar 2021 13:13:50 -0500, Joseph Reichman wrote:

>Who uses tape 
> 
Programmers who want large blocks?

>I went to bsam trying to speed up my application wonder if going to bsam 
>
>Does anything positive for me 
>
>> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin wrote:
>> 
>> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
>> 
>>> It disk then documentation says the system only supports tape at this time 
>>> is That true ?
>>> 
>> Have you any reason to doubt it?
>> 
>> I suspect it's a hardware limitation.
>> 
> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote:
 
 On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
 
> I have 100 files concatenated that are normally processed by qsam with a 
> lrecl 31996 and blksize 32000
> 
> Since processing takes a long time I was looking to speed things up by 
> specifying a blksize of 32 in the DCBE 
> 
 What device type?
 
> After the first read using bsam read macro I looked at the first 4 bytes 
> ( Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed 
> to me that it was still processing blksize of 32,000 

-- gil

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

Re: Large block interface for VB

[Joseph Reichman]

Who uses tape 

I went to bsam trying to speed up my application wonder if going to bsam 

Does anything positive for me 

> On Mar 1, 2021, at 1:10 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:
> 
>> It disk then documentation says the system only supports tape at this time 
>> is That true ?
>> 
> Have you any reason to doubt it?
> 
> I suspect it's a hardware limitation.
> 
 On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote:
>>> 
>>> On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
>>> 
 I have 100 files concatenated that are normally processed by qsam with a 
 lrecl 31996 and blksize 32000
 
 Since processing takes a long time I was looking to speed things up by 
 specifying a blksize of 32 in the DCBE 
 
>>> What device type?
>>> 
 After the first read using bsam read macro I looked at the first 4 bytes ( 
 Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to 
 me that it was still processing blksize of 32,000 
> 
> -- 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: Large block interface for VB

[Paul Gilmartin]

On Mon, 1 Mar 2021 11:24:57 -0500, Joseph Reichman wrote:

>It disk then documentation says the system only supports tape at this time is 
>That true ?
> 
Have you any reason to doubt it?

I suspect it's a hardware limitation.

>> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin wrote:
>> 
>> On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
>> 
>>> I have 100 files concatenated that are normally processed by qsam with a 
>>> lrecl 31996 and blksize 32000
>>> 
>>> Since processing takes a long time I was looking to speed things up by 
>>> specifying a blksize of 32 in the DCBE 
>>> 
>> What device type?
>> 
>>> After the first read using bsam read macro I looked at the first 4 bytes ( 
>>> Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to 
>>> me that it was still processing blksize of 32,000 

-- gil

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

Re: FTP-SSL from z/OS client to Linux

[Wendell Lovewell]

Hi Steve. 

I've found the SSL trace information written into a USS file to be somewhat 
easier to use.  You can turn on GSK_TRACE flags and specify a trace file using 
STDENV similar to the example below IF you specify the 
PARM=('ENVAR("_CEE_ENVFILE_S=DD:STDENV") (the _S is crucial or the DD * input 
won't work):

//FTPS EXEC PGM=FTP,REGION=4M,
// PARM=('ENVAR("_CEE_ENVFILE_S=DD:STDENV")/ftp.linuxsite.com 21 -e')
//STDENV   DD *
GSK_PROTOCOL_TLSV1_2=ON
GSK_TRACE=0x
GSK_TRACE_FILE=/tmp/gskfile.trc
//*
//SYSFTPD  DD *,SYMBOLS=(JCLONLY)
CLIENTERRCODES EXTENDED
EPSV4  TRUE
EXTENSIONSAUTH_TLS
FWFRIENDLYTRUE
KEYRING /
PASSIVEIGNOREADDR  TRUE
SECUREIMPLICITZOSFALSE
SECURE_FTPREQUIRED
SECURE_MECHANISM   TLS
SECURE_DATACONN PRIVATE
SECURE_CTRLCONN PRIVATE
SECURE_HOSTNAMEREQUIRED
TLSMECHANISM   FTP
TLSRFCLEVEL  RFC4217
//* TRACE
//* DEBUG SEC
//* You can also add other debugging or trace options to SYSFTPD
//OUTPUT   DD SYSOUT=*
//INPUTDD *,SYMBOLS=(JCLONLY)
ftpuid
ftppwd
etc
QUIT
//*

The above step doesn't require AT-TLS changes or changes to your FTPDATA 
datasets, but I don't think the changes you've alreayd made there will prevent 
you from specifying the GSK options via STDENV.  

With the GSK_TRACE flags set, the SSL information will be written to the file 
you specify in GSK_TRACE_FILE.  There is a USS utility named gsktrace that you 
will need to read the trace file and interpret it into something you can read.  
The format is gsktrace > gskfile.trc > gsk.out

The gsktrace output will be pretty detailed, but you can usually find an error 
of some kind. 

These manuals, especially the first one, will probably help:
SC14-7495-30 Cryptographic Services System Secure Sockets Layer Programming
SC27-3651-30 IP Configuration Reference
GC27-3652-30 IP Diagnosis Guide
Wendell


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

Re: Large block interface for VB

[Joseph Reichman]

It disk then documentation says the system only supports tape at this time is 
That true ?

> On Mar 1, 2021, at 11:22 AM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:
> 
>> I have 100 files concatenated that are normally processed by qsam with a 
>> lrecl 31996 and blksize 32000
>> 
>> Since processing takes a long time I was looking to speed things up by 
>> specifying a blksize of 32 in the DCBE 
>> 
> What device type?
> 
>> After the first read using bsam read macro I looked at the first 4 bytes ( 
>> Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to 
>> me that it was still processing blksize of 32,000 
> 
> -- 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: Large block interface for VB

[Paul Gilmartin]

On Mon, 1 Mar 2021 09:12:59 -0500, Joseph Reichman wrote:

>I have 100 files concatenated that are normally processed by qsam with a lrecl 
>31996 and blksize 32000
>
>Since processing takes a long time I was looking to speed things up by 
>specifying a blksize of 32 in the DCBE 
> 
What device type?

>After the first read using bsam read macro I looked at the first 4 bytes ( 
>Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to me 
>that it was still processing blksize of 32,000 

-- gil

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

Large block interface for VB

[Joseph Reichman]

I have 100 files concatenated that are normally processed by qsam with a lrecl 
31996 and blksize 32000

Since processing takes a long time I was looking to speed things up by 
specifying a blksize of 32 in the DCBE 

After the first read using bsam read macro I looked at the first 4 bytes ( 
Block descriptor word ) and it was x’7C4A’ which is 31,888 which seemed to me 
that it was still processing blksize of 32,000 

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

Re: z/OS ssh git issue

[Lionel B Dyck]

That is exactly what I have which is why this is baffling  ☹

_
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Monday, March 1, 2021 6:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

I know you responded back with the TAG ENV vars.  Here are all of mine that are 
set in GITENV.sh

# ASCII support environment values   
export _BPXK_AUTOCVT='ON'
export _CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)" 
export _TAG_REDIR_ERR=txt
export _TAG_REDIR_IN=txt 
export _TAG_REDIR_OUT=txt



_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B Dyck
Sent: Monday, March 1, 2021 6:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

They are set.

_TAG_REDIR_IN=txt 
_TAG_REDIR_OUT=txt
_TAG_REDIR_ERR=txt

Thanks for the suggestion.  Now you can see why we are baffled.

_
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Sunday, February 28, 2021 6:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

Make sure you also have the following set:

export _TAG_REDIR_ERR=txt
export _TAG_REDIR_IN=txt
export _TAG_REDIR_OUT=txt


On 28/02/2021 10:45 pm, Lionel B Dyck wrote:
> I have in the environment on this system and on the working systems.
>
> _BPXK_AUTOCVT=ON
> _CEE_RUNOPTS=FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)
>
> And I'm not sure which files you are asking about being tagged?
>
> My ssh keys are untagged if that is your question - the same as on my working 
> system.
>
> __
> ___
> Lionel B Dyck <
> Website: www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is 
> what you are, reputation merely what others think you are." - John 
> Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Michael Babcock
> Sent: Saturday, February 27, 2021 8:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS ssh git issue
>
> Is AUTOCONVERT turned on in USS?  And the files are tagged?
>
> On Sat, Feb 27, 2021 at 2:24 PM Lionel B Dyck  wrote:
>
>> I’m having an issue on a test lpar with git for z/OS – both version
>> 2.14 and the latest 2.26 ports.
>>
>>
>>
>> I’ve looked at this as have several others without success.
>>
>>
>>
>> When I attempt a git clone I get this error:
>>
>>
>>
>> fatal: protocol error: bad line length character: ---Á
>>
>>
>>
>> When I do a ssh g...@github.com  
>> git-receive-pack lbdyck/qtab.git I get this:
>>
>>
>>
>>
>> --ÄÁ---Ä--ÃÃ-À--ÄÂÂ--Á-/ÄÁ---À/--ÊÁÃËÇÁ/ÀË_/ËÈÁÊÊÁø?ÊÈ-ËÈ
>> / ÈÍË-ÊÁ ø?ÊÈ-ËÈ/ÈÍË-Î--ÀÁ%ÁÈÁ-ÊÁÃË-ËÑÀÁ-Â/>À---,-ÉÍÑÁÈ-/È?_ÑÄ-?Ã
>>
>> Ë-ÀÁ%È/-øÍËÇ-?øÈÑ?>Ë-?¦ÁÄÈ-Ã?Ê_/È-ËÇ/--/ÅÁ>È-ÅÑÈÅÑÈÇÍÂ-Å-ÃÃ-Ä/À-
>> -
>> 
>>
>>
>>
>>
>> If I do the same ssh g...@github.com  
>> git-receive-pack lbdyck/qtab.git on one of my other systems it looks 
>> like
>> this:
>>
>>
>>
>> 00ce342c27f0363f6d24cbb68e8ace7454218d4828a2
>> refs/heads/masterreport-status
>> report-status-v2 delete-refs side-band-64k quiet atomic
>>
>> ofs-delta push-options object-format=sha1
>> agent=git/github-g2ff1cad44179
>>
>>
>>
>>
>> We’ve looked at the TCP/IP setup, the SSH setup, and the Git setup 
>> with no joy.  We’ve also confirmed that the ssh public key has been 
>> properly added to github.
>>
>>
>>
>> Can anyone provide any suggestions that will help resolve this?
>>
>>
>>
>> Thank you
>>
>>
>>
>>
>>
>> ­­­__
>> _
>> __
>> 
>>
>> Lionel B Dyck <
>>
>> Website:   www.lbdsoftware.com
>>
>>
>>
>> "Worry more about your character than your reputation.  Character is 
>> what you are, reputation merely 

Re: z/OS ssh git issue

[Jousma, David]

I know you responded back with the TAG ENV vars.  Here are all of mine that are 
set in GITENV.sh

# ASCII support environment values   
export _BPXK_AUTOCVT='ON'
export _CEE_RUNOPTS="FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)" 
export _TAG_REDIR_ERR=txt
export _TAG_REDIR_IN=txt 
export _TAG_REDIR_OUT=txt



_
Dave Jousma
AVP | Director, Technology Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Lionel B Dyck
Sent: Monday, March 1, 2021 6:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

They are set.

_TAG_REDIR_IN=txt 
_TAG_REDIR_OUT=txt
_TAG_REDIR_ERR=txt

Thanks for the suggestion.  Now you can see why we are baffled.

_
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Sunday, February 28, 2021 6:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

Make sure you also have the following set:

export _TAG_REDIR_ERR=txt
export _TAG_REDIR_IN=txt
export _TAG_REDIR_OUT=txt


On 28/02/2021 10:45 pm, Lionel B Dyck wrote:
> I have in the environment on this system and on the working systems.
>
> _BPXK_AUTOCVT=ON
> _CEE_RUNOPTS=FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)
>
> And I'm not sure which files you are asking about being tagged?
>
> My ssh keys are untagged if that is your question - the same as on my working 
> system.
>
> __
> ___
> Lionel B Dyck <
> Website: www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is 
> what you are, reputation merely what others think you are." - John 
> Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Michael Babcock
> Sent: Saturday, February 27, 2021 8:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS ssh git issue
>
> Is AUTOCONVERT turned on in USS?  And the files are tagged?
>
> On Sat, Feb 27, 2021 at 2:24 PM Lionel B Dyck  wrote:
>
>> I’m having an issue on a test lpar with git for z/OS – both version
>> 2.14 and the latest 2.26 ports.
>>
>>
>>
>> I’ve looked at this as have several others without success.
>>
>>
>>
>> When I attempt a git clone I get this error:
>>
>>
>>
>> fatal: protocol error: bad line length character: ---Á
>>
>>
>>
>> When I do a ssh g...@github.com  
>> git-receive-pack lbdyck/qtab.git I get this:
>>
>>
>>
>>
>> --ÄÁ---Ä--ÃÃ-À--ÄÂÂ--Á-/ÄÁ---À/--ÊÁÃËÇÁ/ÀË_/ËÈÁÊÊÁø?ÊÈ-ËÈ
>> / ÈÍË-ÊÁ ø?ÊÈ-ËÈ/ÈÍË-Î--ÀÁ%ÁÈÁ-ÊÁÃË-ËÑÀÁ-Â/>À---,-ÉÍÑÁÈ-/È?_ÑÄ-?Ã
>>
>> Ë-ÀÁ%È/-øÍËÇ-?øÈÑ?>Ë-?¦ÁÄÈ-Ã?Ê_/È-ËÇ/--/ÅÁ>È-ÅÑÈÅÑÈÇÍÂ-Å-ÃÃ-Ä/À-
>> -
>> 
>>
>>
>>
>>
>> If I do the same ssh g...@github.com  
>> git-receive-pack lbdyck/qtab.git on one of my other systems it looks 
>> like
>> this:
>>
>>
>>
>> 00ce342c27f0363f6d24cbb68e8ace7454218d4828a2
>> refs/heads/masterreport-status
>> report-status-v2 delete-refs side-band-64k quiet atomic
>>
>> ofs-delta push-options object-format=sha1
>> agent=git/github-g2ff1cad44179
>>
>>
>>
>>
>> We’ve looked at the TCP/IP setup, the SSH setup, and the Git setup 
>> with no joy.  We’ve also confirmed that the ssh public key has been 
>> properly added to github.
>>
>>
>>
>> Can anyone provide any suggestions that will help resolve this?
>>
>>
>>
>> Thank you
>>
>>
>>
>>
>>
>> ­­­__
>> _
>> __
>> 
>>
>> Lionel B Dyck <
>>
>> Website:   www.lbdsoftware.com
>>
>>
>>
>> "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
>>
> --
> Michael Babcock
> OneMain Financial
> z/OS Systems Programmer, Lead
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to 

Re: BLS18160D Response

[Matthew Stitt]

An SDC2 abend on a JES2 warm start?  Sounds very familiar.  I spent quite a bit 
of time with support over that.  Here is what was finally determined:

 OA58190 has changed the JES2 checkpoint structure, which is independent of 
user activity. Such internal changes are necessary in order to support new 
functionality. Therefore all JES2 members accessing such a checkpoint 
thereafter need the mentioned compatibility APAR OA59665/UJ03635.

Thus.  If these APARs/PTFs are applied, there is no falling back.  And a 
fallback attempt causes the SDC2 abend.

Matthew

On Sun, 28 Feb 2021 08:08:55 -0800, Ed Jaffe  
wrote:

>On 2/27/2021 7:48 PM, Mark Jacobs wrote:
>> >From the FM;
>>
>> The summary dump data contains data captured closest to the time of the 
>> failure. If you reply Y to use this data, IPCS will not be able to display 
>> storage keys using the DISPLAY(MACHINE) parameter.
>
>Yeah, but...
>
>I don't experience issues displaying keys using DISPLAY(MACHINE) when
>responding 'Y' to BLS18160D.
>
>I tried it just now. I initialized a dump still lying around from
>yesterday (SLIP to capture an SDC2 abend in an SRB) and responded 'Y' to
>the BLS18160D prompt:
>
>  IKJ56650I TIME-07:42:42 AM. CPU-00:00:03 SERVICE-22127
>SESSION-00:00:47 FEBRUARY 28,2021
>  BLS18122I Initialization in progress for
>DSNAME('SYS3.DUMP.D210227.T222342.EDJX2.S8')
>  BLS18124I TITLE=SLIP DUMP ID=EEJ6
>  BLS18223I Dump written by z/OS 02.04.00-0 SLIP - level same as IPCS level
>  BLS18558I This redactable dump has not been post-processed to protect
>sensitive data
>  BLS18222I z/Architecture mode system
>  BLS18160D May summary dump data be used by dump access?  Enter Y to
>use, N to bypass.
>y
>  BLS18255I Dump Init    Elapsed Time  CPU Time
>    Input I/O   00:00:01.205379 00:00:01.041953
>    DDIR    00:00:00.842453 00:00:00.605543
>  BLS18123I 161,077 blocks, 670,080,320 bytes, in
>DSNAME('SYS3.DUMP.D210227.T222342.EDJX2.S8')
>  IKJ56650I TIME-07:44:17 AM. CPU-00:00:07 SERVICE-42085
>SESSION-00:02:21 FEBRUARY 28,2021
>  BLS18224I Dump of z/OS 02.04.00-0 - level same as IPCS level
>  ***
>
>STATUS shows PSW and registers for the DC2 abend:
>
>CPU STATUS:
>PSW=47045000 8000  019A7318
>     (Running in AR, key 0, AMODE 31, DAT ON, SUPERVISOR STATE)
>     Enabled for PER I/O EXT MCH
>    ASID(X'0072') 019A7318. IEANUC01.IAXV6+24D0 IN READ ONLY NUCLEUS
>   ASCB114 at FBD400, JOB(EDJX2), for the home ASID
>   ASXB114 at AFD000 for the home ASID. No block is dispatched
>   HOME ASID: 0072 PRIMARY ASID: 0072 SECONDARY ASID: 0072
>
>   General purpose register values
>     Left halves of all registers contain zeros
>  0-3  8400  84DC2000  0001  
>  4-7    029B9000  00FBD400  01DDDF00
>  8-11   042FCC30    08004000
>     12-15 019A8550  042FE178  042FE000  66004020
>
>SUMDUMP captures storage on both sides of the PSW and every register. I
>have 'IP SETDEF DISPLAY(MACHINE)' in effect. Listing the PSW via 'IP L
>019A7318' returns KEY(08):
>
>LIST 019A7318. ASID(X'0072') LENGTH(X'2000') AREA
>ASID(X'0072') ADDRESS(019A7318.) KEY(00)
>019A7318. B24D001C E31D 00045811 00889110 |.(..Thj.|
>019A7328. 1008A784 0009C019 04C0D000 C0F9FE00 |..xd..{..{}.{9..|
>
>'IP L 5R!' returns KEY(00):
>
>LIST 029B9000. ASID(X'0072') LENGTH(X'2000') AREA
>ASID(X'0072') ADDRESS(029B9000.) KEY(08)
>029B9000. C9C1E7C3 D7E3C2D3 0012  |IAXCPTBL|
>029B9010. 0012 0040 042FC000  |... ..{.|
>
>'IP L 7R!' returns KEY(00):
>
>LIST 01DDDF00. ASID(X'0072') LENGTH(X'2000') AREA
>ASID(X'0072') ADDRESS(01DDDF00.) KEY(00)
>01DDDF00. D9C3C540 002E65A3 0FFE 0EB6 |RCE ...t|
>01DDDF10. 050B 00350202 142E 28C0 |...{|
>
>'IP L 9R!' returns KEY(00):
>
>LIST 042FCC30. ASID(X'0072') LENGTH(X'2000') AREA
>ASID(X'0072') ADDRESS(042FCC30.) KEY(00)
>042FCC30.  009A   ||
>042FCC40.  042FC000  042FC004 |..{...{.|
>
>Same with all of the other registers that look like addresses. Not one
>does not show the KEY information. I get similar results when processing
>dumps in TCB mode. Pretty much everything pointed to by the RTM2WA is
>included in the SUMDUMP and KEY information seems to be routinely provided.
>
>Perhaps there is some pathological situation where that information
>doesn't display?
>
>--

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

Re: z/OS ssh git issue

[Lionel B Dyck]

They are set.

_TAG_REDIR_IN=txt 
_TAG_REDIR_OUT=txt
_TAG_REDIR_ERR=txt

Thanks for the suggestion.  Now you can see why we are baffled.

_
Lionel B Dyck <
Website: www.lbdsoftware.com

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Crayford
Sent: Sunday, February 28, 2021 6:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS ssh git issue

Make sure you also have the following set:

export _TAG_REDIR_ERR=txt
export _TAG_REDIR_IN=txt
export _TAG_REDIR_OUT=txt


On 28/02/2021 10:45 pm, Lionel B Dyck wrote:
> I have in the environment on this system and on the working systems.
>
> _BPXK_AUTOCVT=ON
> _CEE_RUNOPTS=FILETAG(AUTOCVT,AUTOTAG) POSIX(ON)
>
> And I'm not sure which files you are asking about being tagged?
>
> My ssh keys are untagged if that is your question - the same as on my working 
> system.
>
> __
> ___
> Lionel B Dyck <
> Website: www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is 
> what you are, reputation merely what others think you are." - John 
> Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Michael Babcock
> Sent: Saturday, February 27, 2021 8:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: z/OS ssh git issue
>
> Is AUTOCONVERT turned on in USS?  And the files are tagged?
>
> On Sat, Feb 27, 2021 at 2:24 PM Lionel B Dyck  wrote:
>
>> I’m having an issue on a test lpar with git for z/OS – both version
>> 2.14 and the latest 2.26 ports.
>>
>>
>>
>> I’ve looked at this as have several others without success.
>>
>>
>>
>> When I attempt a git clone I get this error:
>>
>>
>>
>> fatal: protocol error: bad line length character: ---Á
>>
>>
>>
>> When I do a ssh g...@github.com  
>> git-receive-pack lbdyck/qtab.git I get this:
>>
>>
>>
>>
>> --ÄÁ---Ä--ÃÃ-À--ÄÂÂ--Á-/ÄÁ---À/--ÊÁÃËÇÁ/ÀË_/ËÈÁÊÊÁø?ÊÈ-ËÈ
>> / ÈÍË-ÊÁ ø?ÊÈ-ËÈ/ÈÍË-Î--ÀÁ%ÁÈÁ-ÊÁÃË-ËÑÀÁ-Â/>À---,-ÉÍÑÁÈ-/È?_ÑÄ-?Ã
>>
>> Ë-ÀÁ%È/-øÍËÇ-?øÈÑ?>Ë-?¦ÁÄÈ-Ã?Ê_/È-ËÇ/--/ÅÁ>È-ÅÑÈÅÑÈÇÍÂ-Å-ÃÃ-Ä/À-
>> -
>> 
>>
>>
>>
>>
>> If I do the same ssh g...@github.com  
>> git-receive-pack lbdyck/qtab.git on one of my other systems it looks 
>> like
>> this:
>>
>>
>>
>> 00ce342c27f0363f6d24cbb68e8ace7454218d4828a2
>> refs/heads/masterreport-status
>> report-status-v2 delete-refs side-band-64k quiet atomic
>>
>> ofs-delta push-options object-format=sha1
>> agent=git/github-g2ff1cad44179
>>
>>
>>
>>
>> We’ve looked at the TCP/IP setup, the SSH setup, and the Git setup 
>> with no joy.  We’ve also confirmed that the ssh public key has been 
>> properly added to github.
>>
>>
>>
>> Can anyone provide any suggestions that will help resolve this?
>>
>>
>>
>> Thank you
>>
>>
>>
>>
>>
>> ­­­__
>> _
>> __
>> 
>>
>> Lionel B Dyck <
>>
>> Website:   www.lbdsoftware.com
>>
>>
>>
>> "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
>>
> --
> Michael Babcock
> OneMain Financial
> z/OS Systems Programmer, Lead
>
> --
> 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: BLS18160D Response

[Barbara Nitz]

On Sun, 28 Feb 2021 08:08:55 -0800, Ed Jaffe  
wrote:

>I don't experience issues displaying keys using DISPLAY(MACHINE) when
>responding 'Y' to BLS18160D.

Did you compare the keys with what rsmdata knows about the key of the page? I 
learned to use 'yes' to the BLS message and only to use the key for the page 
that rsmdata shows.

Regards, Barbara

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

Re: Colours on screen (mainframe history question)

[Martin Packer]

Perhaps if you grease lightning it turns green. :-)

TGIM. :-)

Martin Packer

WW z/OS Performance, Capacity and Architecture, IBM Technology Sales

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

Mainframe, Performance, Topics Podcast Series (With Marna Walle): 
https://anchor.fm/marna-walle

Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Tony Harminc 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   01/03/2021 04:15
Subject:[EXTERNAL] Re: Colours on screen (mainframe history 
question)
Sent by:IBM Mainframe Discussion List 



On Fri, 26 Feb 2021 at 10:56, Jim Elliott  wrote:
>
> I was working in the IBM Toronto Lab prior to the 3279 announcement and 
was a tester for the product (developed at IBM Hursley). Somewhere I have 
a photo of myself sitting at my 3279 when I got an award. I still have a 
copy of a pre-announce version of a paper on developing colour 
applications (the doc is printed in colour, unusual for the time). 
Remember the lightning bolts as the early 3279 models displayed graphics?

PS lightning. But IIRC green, which isnt'exactly usual for ordinary
lightning. Didn't Mike Cowlishaw do some work on (or with) GDDM? I
seem to remember that he mentioned the PS lightning in a doc.

Tony H.

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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