Re: File transfer question

2025-01-19 Thread Radoslaw Skorupka

It really depends on the text and its purpose.
IMHO "Internet e-mail" means anything you can imagine. And it is very 
rare to transfer it from mainframe to PC.
However for most people "e-mail" is just a text. Or "word processor 
text" - I mean font size, bold, underline, font colour, font type, etc.

But it is *NOT* a text. Word document is not a text. Not pure text.
I have no idea where the "--" or "-- " can be found in an "e-mail". The 
only place I see is my signature. :-) And in this place remaining spaces 
are not important.
We can drill the topic ad absurdum. Analyze hidden spaces (not X'20'), 
false "a" characters, UNICODE, etc. etc. But... who cares?
When processing business data we have names and numbers. No remaining 
spaces. When transferring source code we don't care about remaining 
spaces. Where is the *real* case where remaining spaces do the difference?


--
Radoslaw Skorupka
Lodz, Poland




W dniu 19.01.2025 o 14:11, Seymour J Metz pisze:

Spaces most definitely are part of text. E.g., in Internet e-mail, a line containing "--" 
and a line containing "-- " are very different.

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




From: IBM Mainframe Discussion List  on behalf of Radoslaw 
Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 19, 2025 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer question

External Message: Use Caution


IMHO it works as expected.
When you want text you get text lines (not records). No remaining spaces
as it is not part of text. CRLF added during conversion from record to
line.
When you want the content 1:1 you usually don't expect CRLF, however you
can convert records to lines ended with CRLF. Note, CRLF is for *text*,
not for any file format on PC.

The question is how to transfer a dataset to file with EBCDIC->ASCII
conversion and spaces preservation. Very rare IMHO, however one may want
it. Why? Just to discuss the case on IBM-MAIN. ;-)
OK, for that case IND$FILE has no support, AFAIK. However you can
translate dataset from EBCDIC to ASCII. DatasetE -> DatasetA. Then
transfer it using CRLF and no translation. First step will translate
X'40' to X'20' and second step will transfer it with no changes except
CRLF added at end of record/line.

BTW: I use IND$FILE, but not for regular transfers or big files. IMHO it
is "quick & dirty" way to transfer some script or XMITted PDS. Ad hoc.
For production there is FTP or some MFT solution. With all the features
including CRLF, translation, translation tables, etc.

--
Radoslaw Skorupka
Lodz, Poland




W dniu 17.01.2025 o 23:12, Tom Brennan pisze:

On z/OS 3.1, I just created a 3 line member in my FB/80 CNTL PDS as:

000
11
22

That's unnumbered, so there's nothing but spaces to the right.  I
downloaded to my PC with ASCII turned off but CRLF turned on. IND$FILE
(and the terminal emulator) gave me this:

000 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f040
020 4040 4040 4040 4040 4040 4040 4040 4040
040 4040 4040 4040 4040 4040 4040 4040 4040
060 4040 4040 4040 4040 4040 4040 4040 4040
100 4040 4040 4040 4040 4040 4040 4040 4040
120 0d0a f1f1 f1f1 f1f1 f1f1 f1f1 4040 4040
140 4040 4040 4040 4040 4040 4040 4040 4040
160 4040 4040 4040 4040 4040 4040 4040 4040
200 4040 4040 4040 4040 4040 4040 4040 4040
220 4040 4040 4040 4040 4040 4040 4040 4040
240 4040 0d0a f2f2 f2f2 f2f2 f2f2 f2f2 4040
260 4040 4040 4040 4040 4040 4040 4040 4040
300 4040 4040 4040 4040 4040 4040 4040 4040
320 4040 4040 4040 4040 4040 4040 4040 4040
340 4040 4040 4040 4040 4040 4040 4040 4040
360 4040 4040 0d0a 1a00

So that's EBCDIC still, but with CRLF's at the end of each line.
Interestingly, the line ends come at the very end of each 80 byte
record, not after the last non-space character like the ASCII option
trimming does.

Here's the same member downloaded with both ASCII and CRLF options:

000 3030 3030 3030 3030 3030 3030 3030 300d
020 0a31 3131 3131 3131 3131 310d 0a32 3232
040 3232 3232 3232 320d 0a1a

So like Gil mentioned, CRLF without ASCII would allow text file
conversion to be done on the PC side while still giving the record
splits.  In other words, we might have a possible use for this :)

This was using a particular terminal emulator I happen to have on my
Windows PC.  Other emulators may have different results.

ALCON!

On 1/17/2025 1:16 PM, Phil Smith III wrote:

"ALCON"?

This is uploading TO z/OS. That's why the question: there's no
"records" per se in a bytestream, so there's no clear way to decide
where to put them.

See the replies by Charles and Michael. Charles notes that it's not
*adding* the CR/LF, it's *honoring* them, and Michael posited a
plausible (if exceedingly rare) use case.

-Original Message-
From: IBM Mainframe Discussion List  On
Behalf Of Harry Wahl
Sent: Frid

Re: File transfer question

2025-01-19 Thread Seymour J Metz
No, Internet e-mail means RFC 5321, RFC 5322, associated RFCs, and their 
antecedents.

Yes, who cares whether their e-mail client display or hides part of the 
message? What? Where did all of those raised hands come from?

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




From: IBM Mainframe Discussion List  on behalf of 
Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 19, 2025 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer question

External Message: Use Caution


It really depends on the text and its purpose.
IMHO "Internet e-mail" means anything you can imagine. And it is very
rare to transfer it from mainframe to PC.
However for most people "e-mail" is just a text. Or "word processor
text" - I mean font size, bold, underline, font colour, font type, etc.
But it is *NOT* a text. Word document is not a text. Not pure text.
I have no idea where the "--" or "-- " can be found in an "e-mail". The
only place I see is my signature. :-) And in this place remaining spaces
are not important.
We can drill the topic ad absurdum. Analyze hidden spaces (not X'20'),
false "a" characters, UNICODE, etc. etc. But... who cares?
When processing business data we have names and numbers. No remaining
spaces. When transferring source code we don't care about remaining
spaces. Where is the *real* case where remaining spaces do the difference?

--
Radoslaw Skorupka
Lodz, Poland




W dniu 19.01.2025 o 14:11, Seymour J Metz pisze:
> Spaces most definitely are part of text. E.g., in Internet e-mail, a line 
> containing "--" and a line containing "-- " are very different.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
>
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
> Sent: Sunday, January 19, 2025 8:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: File transfer question
>
> External Message: Use Caution
>
>
> IMHO it works as expected.
> When you want text you get text lines (not records). No remaining spaces
> as it is not part of text. CRLF added during conversion from record to
> line.
> When you want the content 1:1 you usually don't expect CRLF, however you
> can convert records to lines ended with CRLF. Note, CRLF is for *text*,
> not for any file format on PC.
>
> The question is how to transfer a dataset to file with EBCDIC->ASCII
> conversion and spaces preservation. Very rare IMHO, however one may want
> it. Why? Just to discuss the case on IBM-MAIN. ;-)
> OK, for that case IND$FILE has no support, AFAIK. However you can
> translate dataset from EBCDIC to ASCII. DatasetE -> DatasetA. Then
> transfer it using CRLF and no translation. First step will translate
> X'40' to X'20' and second step will transfer it with no changes except
> CRLF added at end of record/line.
>
> BTW: I use IND$FILE, but not for regular transfers or big files. IMHO it
> is "quick & dirty" way to transfer some script or XMITted PDS. Ad hoc.
> For production there is FTP or some MFT solution. With all the features
> including CRLF, translation, translation tables, etc.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> W dniu 17.01.2025 o 23:12, Tom Brennan pisze:
>> On z/OS 3.1, I just created a 3 line member in my FB/80 CNTL PDS as:
>>
>> 000
>> 11
>> 22
>>
>> That's unnumbered, so there's nothing but spaces to the right.  I
>> downloaded to my PC with ASCII turned off but CRLF turned on. IND$FILE
>> (and the terminal emulator) gave me this:
>>
>> 000 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f040
>> 020 4040 4040 4040 4040 4040 4040 4040 4040
>> 040 4040 4040 4040 4040 4040 4040 4040 4040
>> 060 4040 4040 4040 4040 4040 4040 4040 4040
>> 100 4040 4040 4040 4040 4040 4040 4040 4040
>> 120 0d0a f1f1 f1f1 f1f1 f1f1 f1f1 4040 4040
>> 140 4040 4040 4040 4040 4040 4040 4040 4040
>> 160 4040 4040 4040 4040 4040 4040 4040 4040
>> 200 4040 4040 4040 4040 4040 4040 4040 4040
>> 220 4040 4040 4040 4040 4040 4040 4040 4040
>> 240 4040 0d0a f2f2 f2f2 f2f2 f2f2 f2f2 4040
>> 260 4040 4040 4040 4040 4040 4040 4040 4040
>> 300 4040 4040 4040 4040 4040 4040 4040 4040
>> 320 4040 4040 4040 4040 4040 4040 4040 4040
>> 340 4040 4040 4040 4040 4040 4040 4040 4040
>> 360 4040 4040 0d0a 1a00
>>
>> So that's EBCDIC still, but with CRLF's at the end of each line.
>> Interestingly, the line ends come at the very end of each 80 byte
>> record, not after the last non-space character like the ASCII option
>> trimming does.
>>
>> Here's the same member downloaded with both ASCII and CRLF options:
>>
>> 000 3030 3030 3030 3030 3030 3030 3030 300d
>> 020 0a31 3131 3131 3131 3131 310d 0a32 3232
>> 040 3232 3232 3232 320d 0a

EZD1286I ATTLS

2025-01-19 Thread Peter
Hello

I received a rc 5006 initial handshake error while Ftping over tls.

Is it due to any authentication error? I don't see any error

Well we don't run ICSF. Can I implement FTP over ATTLS without ICSF just by
using software default keys ?

Peter

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


Re: Does this make any sense?

2025-01-19 Thread Colin Paice
I saw a similar effect, but with DB2.

The customer was a highly regarded bank, and had some very clever
application programming techniques.  For example
EXEC SQL QUERY Select version from application.table where application =
"PAYROLL"
If version > ...
{
new function
}

So by setting a flag in a table they could "instantly" roll back an
application change. Bravo.

The problem was they did this in every CICS program, and so was issued 1000
times a transaction, and at 1000 transactions a second this SQL query was
being done 1 million times a second.  The customer did not believe us -
till we showed them the CICS trace.   They changed this to store a version
field in an anchor block, so the lookup took 10's of instructions, and the
CPU dropped by 25%.

I was involved in a Java programming problem.
They had a method which opened a file, read a record.  As the subroutine
was exited, Java automatically did garbage collection on the fle handle and
closed the file.
They changed it to pass the handle back to the caller.  The program then
checked to see if the passed handle was 0, if so open the file.

The original people are looking at the wrong problem.They need to use
products like IBM's Application Performance Analyser, or Strobe, which
gives a profile of where the CPU is being used.  For one bank about to go
live for the first time, this showed that 40% of the CPU was in the printf
routine (they had all the debug code compiled in!), and 20% of the CPU in a
badly written SQL query.  These sampling products will also tell you which
files had the most I/O.

Colin




On Sun, 19 Jan 2025 at 13:10, Robert Prins <
05be6ef5bfea-dmarc-requ...@listserv.ua.edu> wrote:

> From LinkedIn:
>
> 
> 2 weeks ago I received the analysis data from a new client that wanted to
> reduce their CPU consumption and improve their performance. They sent me
> the statistical data from their z16 10 LPARS. Information about 89,000+
> files. I analyzed their data and found 2,000+ files *that could be
> improved*
> and would save CPU when improved. *I pulled out 1 file to demonstrate a
> Proof of Concept (POC) for the client. I had the client run the POC and it
> showed a 29% reduction in CPU every time that file will be used. The 29%
> did not include 3 other major adjustments that would save an addition 14%
> CPU and cut the I/O by 75%.* This is just 1 file. The other files can save
> 3% to 52% of their CPU every time they are used in BATCH or ONLINE.
> 
>
> I've been a programmer on IBM since 1985, and the above doesn't make any
> sense to me, how can changing just one file result in a 43% reduction in
> CPU usage?
>
> I've only ever been using PL/I, and using that I did manage to make some
> improvements to code, including reducing the CPU usage of a CRC routine by
> an even larger amount, 99.7% (Yes, ninety-nine-point-seven percent), but
> that was because the old V2.3.0 PL/I Optimizing compiler was absolute shite
> at handling unaligned bit-strings, but WTH can you change about a file to
> get the above reduction in CPU?
>
> Robert
> --
> Robert AH Prins
> robert(a)prino(d)org
> The hitchhiking grandfather 
> Some REXX code for use on z/OS
> 
>
> --
> 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: EZD1286I ATTLS

2025-01-19 Thread Colin Paice
If you contact me offline,I'll see if I can help.  Please send me (offline)
the other trace entries you got

Colin

On Sun, 19 Jan 2025 at 11:20, Peter <
05e4a8a0a03d-dmarc-requ...@listserv.ua.edu> wrote:

> Hello
>
> I received a rc 5006 initial handshake error while Ftping over tls.
>
> Is it due to any authentication error? I don't see any error
>
> Well we don't run ICSF. Can I implement FTP over ATTLS without ICSF just by
> using software default keys ?
>
> Peter
>
> --
> 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: File transfer question

2025-01-19 Thread Phil Smith III
Yes, Shmuel really meant "a line comprising EXACTLY hyphen, hyphen, space, 
newline". That's the standard (if rarely understood) start of a signature, 
which compliant MUAs will strip when quoting.

While I like this standard and use it, I fear that it's fading away.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: Sunday, January 19, 2025 9:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer question

It really depends on the text and its purpose.
IMHO "Internet e-mail" means anything you can imagine. And it is very rare to 
transfer it from mainframe to PC.
However for most people "e-mail" is just a text. Or "word processor text" - I 
mean font size, bold, underline, font colour, font type, etc.
But it is *NOT* a text. Word document is not a text. Not pure text.
I have no idea where the "--" or "-- " can be found in an "e-mail". The only 
place I see is my signature. :-) And in this place remaining spaces are not 
important.
We can drill the topic ad absurdum. Analyze hidden spaces (not X'20'), false 
"a" characters, UNICODE, etc. etc. But... who cares?
When processing business data we have names and numbers. No remaining spaces. 
When transferring source code we don't care about remaining spaces. Where is 
the *real* case where remaining spaces do the difference?

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


Re: Does this make any sense?

2025-01-19 Thread Steve Beaver
Many moons ago In a galaxy far away I learned to sort my input into sequence 
and move to Region=0M and add a large BUFNI and a small BUFND to the VSAM file 
DD then watch the SRB time drop to negligible 


Sent from my iPhone

No one said I could type with one thumb 

> On Jan 19, 2025, at 08:45, Joel Ewing 
> <070400eb8eab-dmarc-requ...@listserv.ua.edu> wrote:
> 
> It's incredible how much CPU (and clock time) can be expended if access to 
> file is doing "unnecessary" IO operations.   One  would hope these days there 
> aren't still any large, poor-blocksize sequential files around, but if 
> default buffering is used on such a file this can cost a lot of Operating 
> System resources to initiate many reads per logical track even if emulated 
> DASD is caching tracks to minimize physical reads to some media
> 
> VSAM file performance can vary even more widely  because the number of blocks 
> read can literally vary by three or more orders of magnitude depending on 
> access pattern and buffer tuning.  A badly tuned, random accessed VSAM file 
> may be required to re-read multiple Index CI blocks and a Data CI block for 
> each record accessed.   This can result in millions of Index block reads, 
> even if  there are only a 100 Index CIs.   I have seen cases where proper 
> tuning of a high-usage VSAM with better buffering or BLSR cut the clock run 
> time and CPU usage of a batch job by a factor of 10 or more.
> 
> So, yes, this makes sense.  An older shop that hasn't taken the time to 
> revisit old job streams and tune file access that was designed decades ago 
> when real memory was constrained and expensive should definitely re-tune.   
> It may now be practical to buffer all Index CI's in memory, or in some cases 
> it even makes sense to change a heavily used VSAM file to a in-memory data 
> structure.
> 
> JC Ewing
> 
>> On 1/19/25 9:06 AM, Robert Prins wrote:
>> From LinkedIn:
>> 
>> 
>> 2 weeks ago I received the analysis data from a new client that wanted to
>> reduce their CPU consumption and improve their performance. They sent me
>> the statistical data from their z16 10 LPARS. Information about 89,000+
>> files. I analyzed their data and found 2,000+ files *that could be improved*
>> and would save CPU when improved. *I pulled out 1 file to demonstrate a
>> Proof of Concept (POC) for the client. I had the client run the POC and it
>> showed a 29% reduction in CPU every time that file will be used. The 29%
>> did not include 3 other major adjustments that would save an addition 14%
>> CPU and cut the I/O by 75%.* This is just 1 file. The other files can save
>> 3% to 52% of their CPU every time they are used in BATCH or ONLINE.
>> 
>> 
>> I've been a programmer on IBM since 1985, and the above doesn't make any
>> sense to me, how can changing just one file result in a 43% reduction in
>> CPU usage?
>> 
>> I've only ever been using PL/I, and using that I did manage to make some
>> improvements to code, including reducing the CPU usage of a CRC routine by
>> an even larger amount, 99.7% (Yes, ninety-nine-point-seven percent), but
>> that was because the old V2.3.0 PL/I Optimizing compiler was absolute shite
>> at handling unaligned bit-strings, but WTH can you change about a file to
>> get the above reduction in CPU?
>> 
>> Robert
> 
> --
> Joel C Ewing
> 
> --
> 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: Physical tape connectivity

2025-01-19 Thread Radoslaw Skorupka

W dniu 18.01.2025 o 17:01, Russell Witt pisze:

Since you already have a license for CA 1, you can do that right now without 
having to purchase or license anything additional. With CA 1 Flexible Storage, 
that functionality is already built into the product at no additional charge or 
license needed. Please contact CA 1 support for more information, or you can 
contact me directly.

Russell Witt
CA 1 Flexible Storage
russell.w...@broadcom.com


Can you provide more details about the solution?
How it is related to CA Cloud Storage for System z on z/OS or CA VTape? 
Is it replacement?

Can user simply write to "cloud tape volume" using IEBGENER or ADRDSSU?
Can DFSMShsm use it as any other tape drives?

--
Radoslaw Skorupka
Lodz, Poland

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


Does this make any sense?

2025-01-19 Thread Robert Prins
>From LinkedIn:


2 weeks ago I received the analysis data from a new client that wanted to
reduce their CPU consumption and improve their performance. They sent me
the statistical data from their z16 10 LPARS. Information about 89,000+
files. I analyzed their data and found 2,000+ files *that could be improved*
and would save CPU when improved. *I pulled out 1 file to demonstrate a
Proof of Concept (POC) for the client. I had the client run the POC and it
showed a 29% reduction in CPU every time that file will be used. The 29%
did not include 3 other major adjustments that would save an addition 14%
CPU and cut the I/O by 75%.* This is just 1 file. The other files can save
3% to 52% of their CPU every time they are used in BATCH or ONLINE.


I've been a programmer on IBM since 1985, and the above doesn't make any
sense to me, how can changing just one file result in a 43% reduction in
CPU usage?

I've only ever been using PL/I, and using that I did manage to make some
improvements to code, including reducing the CPU usage of a CRC routine by
an even larger amount, 99.7% (Yes, ninety-nine-point-seven percent), but
that was because the old V2.3.0 PL/I Optimizing compiler was absolute shite
at handling unaligned bit-strings, but WTH can you change about a file to
get the above reduction in CPU?

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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


Re: File transfer question

2025-01-19 Thread Seymour J Metz
Spaces most definitely are part of text. E.g., in Internet e-mail, a line 
containing "--" and a line containing "-- " are very different.

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




From: IBM Mainframe Discussion List  on behalf of 
Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 19, 2025 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer question

External Message: Use Caution


IMHO it works as expected.
When you want text you get text lines (not records). No remaining spaces
as it is not part of text. CRLF added during conversion from record to
line.
When you want the content 1:1 you usually don't expect CRLF, however you
can convert records to lines ended with CRLF. Note, CRLF is for *text*,
not for any file format on PC.

The question is how to transfer a dataset to file with EBCDIC->ASCII
conversion and spaces preservation. Very rare IMHO, however one may want
it. Why? Just to discuss the case on IBM-MAIN. ;-)
OK, for that case IND$FILE has no support, AFAIK. However you can
translate dataset from EBCDIC to ASCII. DatasetE -> DatasetA. Then
transfer it using CRLF and no translation. First step will translate
X'40' to X'20' and second step will transfer it with no changes except
CRLF added at end of record/line.

BTW: I use IND$FILE, but not for regular transfers or big files. IMHO it
is "quick & dirty" way to transfer some script or XMITted PDS. Ad hoc.
For production there is FTP or some MFT solution. With all the features
including CRLF, translation, translation tables, etc.

--
Radoslaw Skorupka
Lodz, Poland




W dniu 17.01.2025 o 23:12, Tom Brennan pisze:
> On z/OS 3.1, I just created a 3 line member in my FB/80 CNTL PDS as:
>
> 000
> 11
> 22
>
> That's unnumbered, so there's nothing but spaces to the right.  I
> downloaded to my PC with ASCII turned off but CRLF turned on. IND$FILE
> (and the terminal emulator) gave me this:
>
> 000 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f040
> 020 4040 4040 4040 4040 4040 4040 4040 4040
> 040 4040 4040 4040 4040 4040 4040 4040 4040
> 060 4040 4040 4040 4040 4040 4040 4040 4040
> 100 4040 4040 4040 4040 4040 4040 4040 4040
> 120 0d0a f1f1 f1f1 f1f1 f1f1 f1f1 4040 4040
> 140 4040 4040 4040 4040 4040 4040 4040 4040
> 160 4040 4040 4040 4040 4040 4040 4040 4040
> 200 4040 4040 4040 4040 4040 4040 4040 4040
> 220 4040 4040 4040 4040 4040 4040 4040 4040
> 240 4040 0d0a f2f2 f2f2 f2f2 f2f2 f2f2 4040
> 260 4040 4040 4040 4040 4040 4040 4040 4040
> 300 4040 4040 4040 4040 4040 4040 4040 4040
> 320 4040 4040 4040 4040 4040 4040 4040 4040
> 340 4040 4040 4040 4040 4040 4040 4040 4040
> 360 4040 4040 0d0a 1a00
>
> So that's EBCDIC still, but with CRLF's at the end of each line.
> Interestingly, the line ends come at the very end of each 80 byte
> record, not after the last non-space character like the ASCII option
> trimming does.
>
> Here's the same member downloaded with both ASCII and CRLF options:
>
> 000 3030 3030 3030 3030 3030 3030 3030 300d
> 020 0a31 3131 3131 3131 3131 310d 0a32 3232
> 040 3232 3232 3232 320d 0a1a
>
> So like Gil mentioned, CRLF without ASCII would allow text file
> conversion to be done on the PC side while still giving the record
> splits.  In other words, we might have a possible use for this :)
>
> This was using a particular terminal emulator I happen to have on my
> Windows PC.  Other emulators may have different results.
>
> ALCON!
>
> On 1/17/2025 1:16 PM, Phil Smith III wrote:
>> "ALCON"?
>>
>> This is uploading TO z/OS. That's why the question: there's no
>> "records" per se in a bytestream, so there's no clear way to decide
>> where to put them.
>>
>> See the replies by Charles and Michael. Charles notes that it's not
>> *adding* the CR/LF, it's *honoring* them, and Michael posited a
>> plausible (if exceedingly rare) use case.
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On
>> Behalf Of Harry Wahl
>> Sent: Friday, January 17, 2025 3:38 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: File transfer question
>>
>> ALCON:
>>
>> "My question is: Can you devise a scenario where a binary transfer
>> "with CR/LF" makes sense?"
>>
>> What if you are sending a file with a special purpose code page that
>> FTP does not (and possibly cannot) support to a Windows or whatever
>> file system? A file which is known not to contain any CR or LF
>> characters (not that unusual). The records could be of undefined
>> length and still need the CRLF from FTP on the other side for the
>> Windows file system to separate them.
>>
>> Or, for that matter, a file whose data isn't intended for display or
>> any intra-record parsing, such as engineering or scientific data
>> (e.g. CNC or the output of many types of lab equipment). Typically,
>> such data has a predefined

Re: Does this make any sense?

2025-01-19 Thread Allan Staller
Classification: Confidential

Yes the result do make sense.

True story.
A small auto insurer had a custom (vendor written) COBOL program used for 
policy rating.

The complaint was every time the rating program ran, the CPU (370/138) would go 
to 100% utilization.
I was asked to investigate. It turns out that every single data field in the 
program was display (no comp, comp-3 data descriptions).

A quick review of the Cobol LISTX reviewed the following sequence for every 
binary operation.
Pack (original data item)--> temp1
Conver to binary temp1 --> temp2
Perform arithmetic operation on temp2
Convert to decimal --> temp1
Unpack/unsign temp1 --> original.

The sam was true of every decimal operation (without the CVB/CVD instructions.

To finish the story, I did not change a single logic line, only data 
descriptions.
The program run was no longer noticeable after the above changes.

BTW, for those tht have never seen on, there was an analog "CPU meter" on the 
front panel of the 370/138 that was used to validate the results

HTH,


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert Prins
Sent: Sunday, January 19, 2025 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Does this make any sense?

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

>From LinkedIn:


2 weeks ago I received the analysis data from a new client that wanted to 
reduce their CPU consumption and improve their performance. They sent me the 
statistical data from their z16 10 LPARS. Information about 89,000+ files. I 
analyzed their data and found 2,000+ files *that could be improved* and would 
save CPU when improved. *I pulled out 1 file to demonstrate a Proof of Concept 
(POC) for the client. I had the client run the POC and it showed a 29% 
reduction in CPU every time that file will be used. The 29% did not include 3 
other major adjustments that would save an addition 14% CPU and cut the I/O by 
75%.* This is just 1 file. The other files can save 3% to 52% of their CPU 
every time they are used in BATCH or ONLINE.


I've been a programmer on IBM since 1985, and the above doesn't make any sense 
to me, how can changing just one file result in a 43% reduction in CPU usage?

I've only ever been using PL/I, and using that I did manage to make some 
improvements to code, including reducing the CPU usage of a CRC routine by an 
even larger amount, 99.7% (Yes, ninety-nine-point-seven percent), but that was 
because the old V2.3.0 PL/I Optimizing compiler was absolute shite at handling 
unaligned bit-strings, but WTH can you change about a file to get the above 
reduction in CPU?

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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


Re: none

2025-01-19 Thread Paul Gilmartin
On Sun, 19 Jan 2025 13:47:17 +, k.kripke wrote:

>SET DIGEST ON   
>


-- 
gil

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


Re: File transfer question

2025-01-19 Thread Mike Schwab
HMC / I/O definition requires 80 bytes per line (Conner ran into thins
in https://blog.share.org/Technology-Article/i-just-bought-an-ibm-z890-now-what
)

On Sun, Jan 19, 2025 at 7:03 AM Radoslaw Skorupka
<0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
>
> IMHO it works as expected.
> When you want text you get text lines (not records). No remaining spaces
> as it is not part of text. CRLF added during conversion from record to
> line.
> When you want the content 1:1 you usually don't expect CRLF, however you
> can convert records to lines ended with CRLF. Note, CRLF is for *text*,
> not for any file format on PC.
>
> The question is how to transfer a dataset to file with EBCDIC->ASCII
> conversion and spaces preservation. Very rare IMHO, however one may want
> it. Why? Just to discuss the case on IBM-MAIN. ;-)
> OK, for that case IND$FILE has no support, AFAIK. However you can
> translate dataset from EBCDIC to ASCII. DatasetE -> DatasetA. Then
> transfer it using CRLF and no translation. First step will translate
> X'40' to X'20' and second step will transfer it with no changes except
> CRLF added at end of record/line.
>
> BTW: I use IND$FILE, but not for regular transfers or big files. IMHO it
> is "quick & dirty" way to transfer some script or XMITted PDS. Ad hoc.
> For production there is FTP or some MFT solution. With all the features
> including CRLF, translation, translation tables, etc.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> W dniu 17.01.2025 o 23:12, Tom Brennan pisze:
> > On z/OS 3.1, I just created a 3 line member in my FB/80 CNTL PDS as:
> >
> > 000
> > 11
> > 22
> >
> > That's unnumbered, so there's nothing but spaces to the right.  I
> > downloaded to my PC with ASCII turned off but CRLF turned on. IND$FILE
> > (and the terminal emulator) gave me this:
> >
> > 000 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f040
> > 020 4040 4040 4040 4040 4040 4040 4040 4040
> > 040 4040 4040 4040 4040 4040 4040 4040 4040
> > 060 4040 4040 4040 4040 4040 4040 4040 4040
> > 100 4040 4040 4040 4040 4040 4040 4040 4040
> > 120 0d0a f1f1 f1f1 f1f1 f1f1 f1f1 4040 4040
> > 140 4040 4040 4040 4040 4040 4040 4040 4040
> > 160 4040 4040 4040 4040 4040 4040 4040 4040
> > 200 4040 4040 4040 4040 4040 4040 4040 4040
> > 220 4040 4040 4040 4040 4040 4040 4040 4040
> > 240 4040 0d0a f2f2 f2f2 f2f2 f2f2 f2f2 4040
> > 260 4040 4040 4040 4040 4040 4040 4040 4040
> > 300 4040 4040 4040 4040 4040 4040 4040 4040
> > 320 4040 4040 4040 4040 4040 4040 4040 4040
> > 340 4040 4040 4040 4040 4040 4040 4040 4040
> > 360 4040 4040 0d0a 1a00
> >
> > So that's EBCDIC still, but with CRLF's at the end of each line.
> > Interestingly, the line ends come at the very end of each 80 byte
> > record, not after the last non-space character like the ASCII option
> > trimming does.
> >
> > Here's the same member downloaded with both ASCII and CRLF options:
> >
> > 000 3030 3030 3030 3030 3030 3030 3030 300d
> > 020 0a31 3131 3131 3131 3131 310d 0a32 3232
> > 040 3232 3232 3232 320d 0a1a
> >
> > So like Gil mentioned, CRLF without ASCII would allow text file
> > conversion to be done on the PC side while still giving the record
> > splits.  In other words, we might have a possible use for this :)
> >
> > This was using a particular terminal emulator I happen to have on my
> > Windows PC.  Other emulators may have different results.
> >
> > ALCON!
> >
> > On 1/17/2025 1:16 PM, Phil Smith III wrote:
> >> "ALCON"?
> >>
> >> This is uploading TO z/OS. That's why the question: there's no
> >> "records" per se in a bytestream, so there's no clear way to decide
> >> where to put them.
> >>
> >> See the replies by Charles and Michael. Charles notes that it's not
> >> *adding* the CR/LF, it's *honoring* them, and Michael posited a
> >> plausible (if exceedingly rare) use case.
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of Harry Wahl
> >> Sent: Friday, January 17, 2025 3:38 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: File transfer question
> >>
> >> ALCON:
> >>
> >> "My question is: Can you devise a scenario where a binary transfer
> >> "with CR/LF" makes sense?"
> >>
> >> What if you are sending a file with a special purpose code page that
> >> FTP does not (and possibly cannot) support to a Windows or whatever
> >> file system? A file which is known not to contain any CR or LF
> >> characters (not that unusual). The records could be of undefined
> >> length and still need the CRLF from FTP on the other side for the
> >> Windows file system to separate them.
> >>
> >> Or, for that matter, a file whose data isn't intended for display or
> >> any intra-record parsing, such as engineering or scientific data
> >> (e.g. CNC or the output of many types of lab equipment). Typically,
> >> such data has a predefined set of possible values that doesn't
> >> contain CRs or LFs. The CRLF is 

Re: Does this make any sense?

2025-01-19 Thread Joel Ewing
It's incredible how much CPU (and clock time) can be expended if access 
to file is doing "unnecessary" IO operations.   One  would hope these 
days there aren't still any large, poor-blocksize sequential files 
around, but if default buffering is used on such a file this can cost a 
lot of Operating System resources to initiate many reads per logical 
track even if emulated DASD is caching tracks to minimize physical reads 
to some media


VSAM file performance can vary even more widely  because the number of 
blocks read can literally vary by three or more orders of magnitude 
depending on access pattern and buffer tuning.  A badly tuned, random 
accessed VSAM file may be required to re-read multiple Index CI blocks 
and a Data CI block for each record accessed.   This can result in 
millions of Index block reads, even if  there are only a 100 Index 
CIs.   I have seen cases where proper tuning of a high-usage VSAM with 
better buffering or BLSR cut the clock run time and CPU usage of a batch 
job by a factor of 10 or more.


So, yes, this makes sense.  An older shop that hasn't taken the time to 
revisit old job streams and tune file access that was designed decades 
ago when real memory was constrained and expensive should definitely 
re-tune.   It may now be practical to buffer all Index CI's in memory, 
or in some cases it even makes sense to change a heavily used VSAM file 
to a in-memory data structure.


    JC Ewing

On 1/19/25 9:06 AM, Robert Prins wrote:

 From LinkedIn:


2 weeks ago I received the analysis data from a new client that wanted to
reduce their CPU consumption and improve their performance. They sent me
the statistical data from their z16 10 LPARS. Information about 89,000+
files. I analyzed their data and found 2,000+ files *that could be improved*
and would save CPU when improved. *I pulled out 1 file to demonstrate a
Proof of Concept (POC) for the client. I had the client run the POC and it
showed a 29% reduction in CPU every time that file will be used. The 29%
did not include 3 other major adjustments that would save an addition 14%
CPU and cut the I/O by 75%.* This is just 1 file. The other files can save
3% to 52% of their CPU every time they are used in BATCH or ONLINE.


I've been a programmer on IBM since 1985, and the above doesn't make any
sense to me, how can changing just one file result in a 43% reduction in
CPU usage?

I've only ever been using PL/I, and using that I did manage to make some
improvements to code, including reducing the CPU usage of a CRC routine by
an even larger amount, 99.7% (Yes, ninety-nine-point-seven percent), but
that was because the old V2.3.0 PL/I Optimizing compiler was absolute shite
at handling unaligned bit-strings, but WTH can you change about a file to
get the above reduction in CPU?

Robert


--
Joel C Ewing

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


Re: Does this make any sense?

2025-01-19 Thread Jousma, David
Zedc?



From: IBM Mainframe Discussion List  on behalf of 
Robert Prins <05be6ef5bfea-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 19, 2025 10:06:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Does this make any sense?




>From LinkedIn:


2 weeks ago I received the analysis data from a new client that wanted to
reduce their CPU consumption and improve their performance. They sent me
the statistical data from their z16 10 LPARS. Information about 89,000+
files. I analyzed their data and found 2,000+ files *that could be improved*
and would save CPU when improved. *I pulled out 1 file to demonstrate a
Proof of Concept (POC) for the client. I had the client run the POC and it
showed a 29% reduction in CPU every time that file will be used. The 29%
did not include 3 other major adjustments that would save an addition 14%
CPU and cut the I/O by 75%.* This is just 1 file. The other files can save
3% to 52% of their CPU every time they are used in BATCH or ONLINE.


I've been a programmer on IBM since 1985, and the above doesn't make any
sense to me, how can changing just one file result in a 43% reduction in
CPU usage?

I've only ever been using PL/I, and using that I did manage to make some
improvements to code, including reducing the CPU usage of a CRC routine by
an even larger amount, 99.7% (Yes, ninety-nine-point-seven percent), but
that was because the old V2.3.0 PL/I Optimizing compiler was absolute shite
at handling unaligned bit-strings, but WTH can you change about a file to
get the above reduction in CPU?

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 

Some REXX code for use on z/OS


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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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


Re: File transfer question

2025-01-19 Thread Andrew Rowley

On 19/01/2025 6:00 am, Kirk Wolf wrote:

I'm 99% certain that there are some "site" options in IBM FTP that will 
round-trip binary VB data.I've seen it discussed on IBM-MAIN, but not for years and I 
can't recall the details.


I should have been more specific, it should be both usable on another 
platform (i.e. documented) and able to be transferred back to z/OS.


I searched some old threads, I didn't test it but there is a suggestion that

BINARY

TYPE E

MODE B

works for a round trip transfer. Is the resulting format documented 
anywhere?


I transferred some data and compared to data transferred with the RDW, 
from what I can see:


- the 4 byte rdw (2 bytes length) is replaced with a 3 byte field

- the length is the length of the data without rdw i.e. 4 bytes less 
than in the RDW


- the first bit in the 3 bytes is set, I don't know what it means.

z/OSMF can also transfer VB data using REST services, it uses a 
different format again. The length field is 4 bytes and is the data 
length only. According to the documentation a round trip should work.


I've seen another example (I can't remember the product) which used the 
RDW format, except that the length was little endian.



FWIW, you can do it easily with Co:Z SFTP.


Yes, Co:Z SFTP works well. Unfortunately it isn't available at all sites.

--
Andrew Rowley
Black Hill Software

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


Re: File transfer question

2025-01-19 Thread Radoslaw Skorupka

IMHO it works as expected.
When you want text you get text lines (not records). No remaining spaces 
as it is not part of text. CRLF added during conversion from record to 
line.
When you want the content 1:1 you usually don't expect CRLF, however you 
can convert records to lines ended with CRLF. Note, CRLF is for *text*, 
not for any file format on PC.


The question is how to transfer a dataset to file with EBCDIC->ASCII 
conversion and spaces preservation. Very rare IMHO, however one may want 
it. Why? Just to discuss the case on IBM-MAIN. ;-)
OK, for that case IND$FILE has no support, AFAIK. However you can 
translate dataset from EBCDIC to ASCII. DatasetE -> DatasetA. Then 
transfer it using CRLF and no translation. First step will translate 
X'40' to X'20' and second step will transfer it with no changes except 
CRLF added at end of record/line.


BTW: I use IND$FILE, but not for regular transfers or big files. IMHO it 
is "quick & dirty" way to transfer some script or XMITted PDS. Ad hoc. 
For production there is FTP or some MFT solution. With all the features 
including CRLF, translation, translation tables, etc.


--
Radoslaw Skorupka
Lodz, Poland




W dniu 17.01.2025 o 23:12, Tom Brennan pisze:

On z/OS 3.1, I just created a 3 line member in my FB/80 CNTL PDS as:

000
11
22

That's unnumbered, so there's nothing but spaces to the right.  I 
downloaded to my PC with ASCII turned off but CRLF turned on. IND$FILE 
(and the terminal emulator) gave me this:


000 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f040
020 4040 4040 4040 4040 4040 4040 4040 4040
040 4040 4040 4040 4040 4040 4040 4040 4040
060 4040 4040 4040 4040 4040 4040 4040 4040
100 4040 4040 4040 4040 4040 4040 4040 4040
120 0d0a f1f1 f1f1 f1f1 f1f1 f1f1 4040 4040
140 4040 4040 4040 4040 4040 4040 4040 4040
160 4040 4040 4040 4040 4040 4040 4040 4040
200 4040 4040 4040 4040 4040 4040 4040 4040
220 4040 4040 4040 4040 4040 4040 4040 4040
240 4040 0d0a f2f2 f2f2 f2f2 f2f2 f2f2 4040
260 4040 4040 4040 4040 4040 4040 4040 4040
300 4040 4040 4040 4040 4040 4040 4040 4040
320 4040 4040 4040 4040 4040 4040 4040 4040
340 4040 4040 4040 4040 4040 4040 4040 4040
360 4040 4040 0d0a 1a00

So that's EBCDIC still, but with CRLF's at the end of each line. 
Interestingly, the line ends come at the very end of each 80 byte 
record, not after the last non-space character like the ASCII option 
trimming does.


Here's the same member downloaded with both ASCII and CRLF options:

000 3030 3030 3030 3030 3030 3030 3030 300d
020 0a31 3131 3131 3131 3131 310d 0a32 3232
040 3232 3232 3232 320d 0a1a

So like Gil mentioned, CRLF without ASCII would allow text file 
conversion to be done on the PC side while still giving the record 
splits.  In other words, we might have a possible use for this :)


This was using a particular terminal emulator I happen to have on my 
Windows PC.  Other emulators may have different results.


ALCON!

On 1/17/2025 1:16 PM, Phil Smith III wrote:

"ALCON"?

This is uploading TO z/OS. That's why the question: there's no 
"records" per se in a bytestream, so there's no clear way to decide 
where to put them.


See the replies by Charles and Michael. Charles notes that it's not 
*adding* the CR/LF, it's *honoring* them, and Michael posited a 
plausible (if exceedingly rare) use case.


-Original Message-
From: IBM Mainframe Discussion List  On 
Behalf Of Harry Wahl

Sent: Friday, January 17, 2025 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer question

ALCON:

"My question is: Can you devise a scenario where a binary transfer 
"with CR/LF" makes sense?"


What if you are sending a file with a special purpose code page that 
FTP does not (and possibly cannot) support to a Windows or whatever 
file system? A file which is known not to contain any CR or LF 
characters (not that unusual). The records could be of undefined 
length and still need the CRLF from FTP on the other side for the 
Windows file system to separate them.


Or, for that matter, a file whose data isn't intended for display or 
any intra-record parsing, such as engineering or scientific data 
(e.g. CNC or the output of many types of lab equipment). Typically, 
such data has a predefined set of possible values that doesn't 
contain CRs or LFs. The CRLF is still necessary on the Windows (or 
whatever) side because a way to separate records is still necessary.


I can think of a lot more examples.

Harry


From: IBM Mainframe Discussion List  on 
behalf of Steve Horein <05b0b4f1358b-dmarc-requ...@listserv.ua.edu>

Sent: Thursday, January 16, 2025 7:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: File transfer question

How's this?
"No."

On Thu, Jan 16, 2025 at 4:02 PM Bob Bridges < 
0587168ababf-dmarc-requ...@listserv.ua.edu> wrote:



Ten replies not counting the OP's, and NOT A SINGLE responder actually
addresse

none

2025-01-19 Thread k.kri...@comcast.net
SET DIGEST ON   




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


Re: TTLSCipherParms if no ICSF

2025-01-19 Thread Keith Gooding

Peter.

Attls uses z/os System SSL component to implement  SSL/TLS so the answer to 
your question should be in the z/OS Cryptographic Services System SSL 
programming manual. Although that document  has a table containing a list of 
supported crypto methods  I cannot see any mention of which ones can be used 
without ICSF.

However the following section implies that most algorithms are supported with  
ICSF but the Elliptic Curve algorithms are not. 

https://www.ibm.com/docs/en/zos/2.5.0?topic=ssl-overview-hardware-cryptographic-features-system

Also if you want to make use of the performance improvements available with  a 
crypto card configured as a crypto accelerator you need ICSF.

I think historically SYSTEM SSL implemented the crypto algorithms itself but 
when ICSF came along it was changed to use ICSF if available.  It was not 
necessary to implement Elliptic Curve algorithms because ICSF is used.

BTW  why would you not want to use ICSF? I think there has been some confusion 
in the past that ICSF requires crypto hardware but  that is not the case.  

Keith Gooding

> On 17 Jan 2025, at 20:22, Peter 
> <05e4a8a0a03d-dmarc-requ...@listserv.ua.edu> wrote:
> Hello
> 
> If there is No ICSF running then what ciphersuites can be used in TTLS
> policy ?
> 
> Is there a default cipher which can be used in the TTLS policy?
> 
> Can someone please point me in the right direction?
> 
> Peter.
> 
> --
> 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: File transfer question

2025-01-19 Thread Phil Smith III
Also: Base64-format certificates either cannot or must be F 80 (I always forget 
which, so get it wrong about half the time). Since that's a more commonly 
uploaded file scenario, I'd suggest that it's even more pervasive.

(Also something RACF could/should handle better.)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Sunday, January 19, 2025 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: File transfer question

HMC / I/O definition requires 80 bytes per line (Conner ran into thins in 
https://blog.share.org/Technology-Article/i-just-bought-an-ibm-z890-now-what
)

On Sun, Jan 19, 2025 at 7:03 AM Radoslaw Skorupka 
<0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
>
> IMHO it works as expected.
> When you want text you get text lines (not records). No remaining 
> spaces as it is not part of text. CRLF added during conversion from 
> record to line.
> When you want the content 1:1 you usually don't expect CRLF, however 
> you can convert records to lines ended with CRLF. Note, CRLF is for 
> *text*, not for any file format on PC.
>
> The question is how to transfer a dataset to file with EBCDIC->ASCII 
> conversion and spaces preservation. Very rare IMHO, however one may 
> want it. Why? Just to discuss the case on IBM-MAIN. ;-) OK, for that 
> case IND$FILE has no support, AFAIK. However you can translate dataset 
> from EBCDIC to ASCII. DatasetE -> DatasetA. Then transfer it using 
> CRLF and no translation. First step will translate X'40' to X'20' and 
> second step will transfer it with no changes except CRLF added at end 
> of record/line.
>
> BTW: I use IND$FILE, but not for regular transfers or big files. IMHO 
> it is "quick & dirty" way to transfer some script or XMITted PDS. Ad hoc.
> For production there is FTP or some MFT solution. With all the 
> features including CRLF, translation, translation tables, etc.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> W dniu 17.01.2025 o 23:12, Tom Brennan pisze:
> > On z/OS 3.1, I just created a 3 line member in my FB/80 CNTL PDS as:
> >
> > 000
> > 11
> > 22
> >
> > That's unnumbered, so there's nothing but spaces to the right.  I 
> > downloaded to my PC with ASCII turned off but CRLF turned on. 
> > IND$FILE (and the terminal emulator) gave me this:
> >
> > 000 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f040
> > 020 4040 4040 4040 4040 4040 4040 4040 4040
> > 040 4040 4040 4040 4040 4040 4040 4040 4040
> > 060 4040 4040 4040 4040 4040 4040 4040 4040
> > 100 4040 4040 4040 4040 4040 4040 4040 4040
> > 120 0d0a f1f1 f1f1 f1f1 f1f1 f1f1 4040 4040
> > 140 4040 4040 4040 4040 4040 4040 4040 4040
> > 160 4040 4040 4040 4040 4040 4040 4040 4040
> > 200 4040 4040 4040 4040 4040 4040 4040 4040
> > 220 4040 4040 4040 4040 4040 4040 4040 4040
> > 240 4040 0d0a f2f2 f2f2 f2f2 f2f2 f2f2 4040
> > 260 4040 4040 4040 4040 4040 4040 4040 4040
> > 300 4040 4040 4040 4040 4040 4040 4040 4040
> > 320 4040 4040 4040 4040 4040 4040 4040 4040
> > 340 4040 4040 4040 4040 4040 4040 4040 4040
> > 360 4040 4040 0d0a 1a00
> >
> > So that's EBCDIC still, but with CRLF's at the end of each line.
> > Interestingly, the line ends come at the very end of each 80 byte 
> > record, not after the last non-space character like the ASCII option 
> > trimming does.
> >
> > Here's the same member downloaded with both ASCII and CRLF options:
> >
> > 000 3030 3030 3030 3030 3030 3030 3030 300d
> > 020 0a31 3131 3131 3131 3131 310d 0a32 3232
> > 040 3232 3232 3232 320d 0a1a
> >
> > So like Gil mentioned, CRLF without ASCII would allow text file 
> > conversion to be done on the PC side while still giving the record 
> > splits.  In other words, we might have a possible use for this :)
> >
> > This was using a particular terminal emulator I happen to have on my 
> > Windows PC.  Other emulators may have different results.
> >
> > ALCON!
> >
> > On 1/17/2025 1:16 PM, Phil Smith III wrote:
> >> "ALCON"?
> >>
> >> This is uploading TO z/OS. That's why the question: there's no 
> >> "records" per se in a bytestream, so there's no clear way to decide 
> >> where to put them.
> >>
> >> See the replies by Charles and Michael. Charles notes that it's not
> >> *adding* the CR/LF, it's *honoring* them, and Michael posited a 
> >> plausible (if exceedingly rare) use case.
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On 
> >> Behalf Of Harry Wahl
> >> Sent: Friday, January 17, 2025 3:38 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: File transfer question
> >>
> >> ALCON:
> >>
> >> "My question is: Can you devise a scenario where a binary transfer 
> >> "with CR/LF" makes sense?"
> >>
> >> What if you are sending a file with a special purpose code page 
> >> that FTP does not (and possibly cannot) support to a Windows or 
> >> whatever file system? A file which is known not to contain any CR 
> >> or LF charac

Re: TTLSCipherParms if no ICSF

2025-01-19 Thread Lennie Bradshaw
< BTW  why would you not want to use ICSF? I think there has been some 
confusion in the past that ICSF requires crypto hardware but  that is not the 
case.>
I think, "no longer the case" would be more accurate.

Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Keith Gooding
Sent: 19 January 2025 18:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TTLSCipherParms if no ICSF


Peter.

Attls uses z/os System SSL component to implement  SSL/TLS so the answer to 
your question should be in the z/OS Cryptographic Services System SSL 
programming manual. Although that document  has a table containing a list of 
supported crypto methods  I cannot see any mention of which ones can be used 
without ICSF.

However the following section implies that most algorithms are supported with  
ICSF but the Elliptic Curve algorithms are not. 

https://www.ibm.com/docs/en/zos/2.5.0?topic=ssl-overview-hardware-cryptographic-features-system

Also if you want to make use of the performance improvements available with  a 
crypto card configured as a crypto accelerator you need ICSF.

I think historically SYSTEM SSL implemented the crypto algorithms itself but 
when ICSF came along it was changed to use ICSF if available.  It was not 
necessary to implement Elliptic Curve algorithms because ICSF is used.

BTW  why would you not want to use ICSF? I think there has been some confusion 
in the past that ICSF requires crypto hardware but  that is not the case.  

Keith Gooding

> On 17 Jan 2025, at 20:22, Peter 
> <05e4a8a0a03d-dmarc-requ...@listserv.ua.edu> wrote:
> Hello
> 
> If there is No ICSF running then what ciphersuites can be used in TTLS 
> policy ?
> 
> Is there a default cipher which can be used in the TTLS policy?
> 
> Can someone please point me in the right direction?
> 
> Peter.
> 
> --
> 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: Does this make any sense?

2025-01-19 Thread Bob Bridges
I took for granted that the original writer means a 29% reduction FOR THAT 
PARTICULAR DATASET, not overall CPU usage.  Maybe I was mistaken.

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

/* If you suck at playing the trumpet, that's probably why. */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert Prins
Sent: Sunday, January 19, 2025 10:07


2 weeks ago I received the analysis data from a new client that wanted to 
reduce their CPU consumption and improve their performance. They sent me the 
statistical data from their z16 10 LPARS. Information about 89,000+ files. I 
analyzed their data and found 2,000+ files *that could be improved* and would 
save CPU when improved. *I pulled out 1 file to demonstrate a Proof of Concept 
(POC) for the client. I had the client run the POC and it showed a 29% 
reduction in CPU every time that file will be used. The 29% did not include 3 
other major adjustments that would save an addition 14% CPU and cut the I/O by 
75%.* This is just 1 file. The other files can save 3% to 52% of their CPU 
every time they are used in BATCH or ONLINE.


I've been a programmer on IBM since 1985, and the above doesn't make any sense 
to me, how can changing just one file result in a 43% reduction in CPU usage?

I've only ever been using PL/I, and using that I did manage to make some 
improvements to code, including reducing the CPU usage of a CRC routine by an 
even larger amount, 99.7% (Yes, ninety-nine-point-seven percent), but that was 
because the old V2.3.0 PL/I Optimizing compiler was absolute shite at handling 
unaligned bit-strings, but WTH can you change about a file to get the above 
reduction in CPU?

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


Re: Does this make any sense?

2025-01-19 Thread Michael Oujesky
I would suspect KSDS VSAM files that were being accessed randomly 
without LSR processing.  Use of LSR or conversion to sequential 
processing is the suspected tweak.


Michael

At 09:06 AM 1/19/2025, Robert Prins wrote:


From LinkedIn:


2 weeks ago I received the analysis data from a new client that wanted to
reduce their CPU consumption and improve their performance. They sent me
the statistical data from their z16 10 LPARS. Information about 89,000+
files. I analyzed their data and found 2,000+ files *that could be improved*
and would save CPU when improved. *I pulled out 1 file to demonstrate a
Proof of Concept (POC) for the client. I had the client run the POC and it
showed a 29% reduction in CPU every time that file will be used. The 29%
did not include 3 other major adjustments that would save an addition 14%
CPU and cut the I/O by 75%.* This is just 1 file. The other files can save
3% to 52% of their CPU every time they are used in BATCH or ONLINE.


I've been a programmer on IBM since 1985, and the above doesn't make any
sense to me, how can changing just one file result in a 43% reduction in
CPU usage?

I've only ever been using PL/I, and using that I did manage to make some
improvements to code, including reducing the CPU usage of a CRC routine by
an even larger amount, 99.7% (Yes, ninety-nine-point-seven percent), but
that was because the old V2.3.0 PL/I Optimizing compiler was absolute shite
at handling unaligned bit-strings, but WTH can you change about a file to
get the above reduction in CPU?

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


--
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: Does this make any sense?

2025-01-19 Thread Seymour J Metz
What are the old and new  DCB attributes?

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




From: IBM Mainframe Discussion List  on behalf of 
Robert Prins <05be6ef5bfea-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, January 19, 2025 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Does this make any sense?

External Message: Use Caution


From LinkedIn:


2 weeks ago I received the analysis data from a new client that wanted to
reduce their CPU consumption and improve their performance. They sent me
the statistical data from their z16 10 LPARS. Information about 89,000+
files. I analyzed their data and found 2,000+ files *that could be improved*
and would save CPU when improved. *I pulled out 1 file to demonstrate a
Proof of Concept (POC) for the client. I had the client run the POC and it
showed a 29% reduction in CPU every time that file will be used. The 29%
did not include 3 other major adjustments that would save an addition 14%
CPU and cut the I/O by 75%.* This is just 1 file. The other files can save
3% to 52% of their CPU every time they are used in BATCH or ONLINE.


I've been a programmer on IBM since 1985, and the above doesn't make any
sense to me, how can changing just one file result in a 43% reduction in
CPU usage?

I've only ever been using PL/I, and using that I did manage to make some
improvements to code, including reducing the CPU usage of a CRC routine by
an even larger amount, 99.7% (Yes, ninety-nine-point-seven percent), but
that was because the old V2.3.0 PL/I Optimizing compiler was absolute shite
at handling unaligned bit-strings, but WTH can you change about a file to
get the above reduction in CPU?

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 

Some REXX code for use on z/OS


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


CBTView ISPF Dialog - quick survey/question

2025-01-19 Thread Lionel B Dyck
If you are using the CBTView dialog (cbttape file 43) you know it
currently uses FTP to get the information from the cbttape website.

Question: Would having an option to use curl be useful?

-- 
Lionel B. Dyck <><
Website:https://github.com/lbdyck

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

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


Re: TTLSCipherParms if no ICSF

2025-01-19 Thread Eric Rossman
It hasn't been the case since around 2000 when we added AES SW support or a 
little later when we added the PKCS#11 interfaces.

From: IBM Mainframe Discussion List  on behalf of 
Lennie Bradshaw 
Sent: Sunday, January 19, 2025 4:59:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [EXTERNAL] Re: TTLSCipherParms if no ICSF

< BTW  why would you not want to use ICSF? I think there has been some 
confusion in the past that ICSF requires crypto hardware but  that is not the 
case.>
I think, "no longer the case" would be more accurate.

Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Keith Gooding
Sent: 19 January 2025 18:31
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TTLSCipherParms if no ICSF


Peter.

Attls uses z/os System SSL component to implement  SSL/TLS so the answer to 
your question should be in the z/OS Cryptographic Services System SSL 
programming manual. Although that document  has a table containing a list of 
supported crypto methods  I cannot see any mention of which ones can be used 
without ICSF.

However the following section implies that most algorithms are supported with  
ICSF but the Elliptic Curve algorithms are not.

https://www.ibm.com/docs/en/zos/2.5.0?topic=ssl-overview-hardware-cryptographic-features-system

Also if you want to make use of the performance improvements available with  a 
crypto card configured as a crypto accelerator you need ICSF.

I think historically SYSTEM SSL implemented the crypto algorithms itself but 
when ICSF came along it was changed to use ICSF if available.  It was not 
necessary to implement Elliptic Curve algorithms because ICSF is used.

BTW  why would you not want to use ICSF? I think there has been some confusion 
in the past that ICSF requires crypto hardware but  that is not the case.

Keith Gooding

> On 17 Jan 2025, at 20:22, Peter 
> <05e4a8a0a03d-dmarc-requ...@listserv.ua.edu> wrote:
> Hello
>
> If there is No ICSF running then what ciphersuites can be used in TTLS
> policy ?
>
> Is there a default cipher which can be used in the TTLS policy?
>
> Can someone please point me in the right direction?
>
> Peter.
>
> --
> 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: Does this make any sense?

2025-01-19 Thread Roger Bolan
Decades ago, when some of us were first learning to code in C, we found a
significant improvement in performance when we switched the datasets we
were using for I/O from unblocked to blocked records.  So it does
make sense.

On Sun, Jan 19, 2025 at 4:13 PM Michael Oujesky 
wrote:

> I would suspect KSDS VSAM files that were being accessed randomly
> without LSR processing.  Use of LSR or conversion to sequential
> processing is the suspected tweak.
>
> Michael
>
> At 09:06 AM 1/19/2025, Robert Prins wrote:
>
> > From LinkedIn:
> >
> >
> >2 weeks ago I received the analysis data from a new client that wanted to
> >reduce their CPU consumption and improve their performance. They sent me
> >the statistical data from their z16 10 LPARS. Information about 89,000+
> >files. I analyzed their data and found 2,000+ files *that could be
> improved*
> >and would save CPU when improved. *I pulled out 1 file to demonstrate a
> >Proof of Concept (POC) for the client. I had the client run the POC and it
> >showed a 29% reduction in CPU every time that file will be used. The 29%
> >did not include 3 other major adjustments that would save an addition 14%
> >CPU and cut the I/O by 75%.* This is just 1 file. The other files can save
> >3% to 52% of their CPU every time they are used in BATCH or ONLINE.
> >
> >
> >I've been a programmer on IBM since 1985, and the above doesn't make any
> >sense to me, how can changing just one file result in a 43% reduction in
> >CPU usage?
> >
> >I've only ever been using PL/I, and using that I did manage to make some
> >improvements to code, including reducing the CPU usage of a CRC routine by
> >an even larger amount, 99.7% (Yes, ninety-nine-point-seven percent), but
> >that was because the old V2.3.0 PL/I Optimizing compiler was absolute
> shite
> >at handling unaligned bit-strings, but WTH can you change about a file to
> >get the above reduction in CPU?
> >
> >Robert
> >--
> >Robert AH Prins
> >robert(a)prino(d)org
> >The hitchhiking grandfather 
> >Some REXX code for use on z/OS
> >
> >
> >--
> >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