Re: Improve OMVS cp performance?

[Attila Fogarasi]

One reason that 48 bit words were so popular in this class of machine is
that there are some significant differential equation solutions which
converge at 48 bit but diverge at 32 bit floating point.  So on the S/360
you would have to use 64 bit floating point to solve them.  When memory
cost USD 1 per bit that difference was a big impact.

On Tue, Nov 17, 2020 at 11:58 AM Wayne Bickerdike  wrote:

> Atlas rang a bell and then I remembered it was used at the Rutherford labs
> in Chilton.
>
> I worked at AERE (Atomic Energy Research Establishment) which was next
> door. They were basically the same campus but AERE was secure and
> Rutherford wasn't.
>
> Ferranti sold two other Atlas installations, one to a joint consortium
> of London
> University  and British
> Petroleum  in 1963, and
> another to the Atomic Energy Research Establishment
> 
> (Harwell)
> in December 1964. The AEA machine was later moved to the Atlas Computer
> Laboratory at Chilton, a few yards outside the boundary fence of Harwell,
> which placed it on civilian lands and thus much easier to access. This
> installation grew to be the largest Atlas, containing 48 kWords of 48-bit
> core
> memory  and 32 tape drives.
>
> Funny story:
>
> Somebody stole a lathe from the Rutherford labs (c. 1968). After that
> happened they installed a gate and security guards at the lab.
>
> At Harwell, we were checked for ID on entry, at Rutherford you were checked
> for lathes on exit!
>
>
>
>
> On Tue, Nov 17, 2020 at 8:42 AM Bernd Oppolzer  >
> wrote:
>
> > Well, I didn't know much about Atlas until now, so I had to do some
> > research;
> > very impressive, indeed. Atlas is about 3 to 5 times faster than the TR
> 4.
> > But in contrast to Atlas, the TR 4 was produced in a sort of small
> > industrial series (35 machines);
> > Atlas seems to be a super computer with very few installations.
> >
> > What strikes me most are the similarities:
> >
> > - 48 bit words
> > - two 24 bit signed integers or six 8 bit-bytes or one 48 bit integer or
> > floating point
> > - or one instruction (two on TR 4 / TR 440)
> > - 24 bit address space (only 16 on the TR 4, later 22 on the TR 440)
> > - 16 k words of core store (32 k max on TR 4, 192 k words on the TR 440,
> > maybe more)
> > - 8 k words of read only memory for supervisor etc. (4 k on TR 4,
> > nothing on TR 440,
> > was loaded at startup time)
> >
> > Atlas was the first implementation of virtual memory,
> > but the first paper on virtual memory is from Fritz-Rudolf Güntsch from
> > 1957
> > https://de.wikipedia.org/wiki/Fritz-Rudolf_G%C3%BCntsch -
> > German wikipedia says: Güntsch is the inventor of virtual memory
> > (German title: F.-R. Güntsch: /Logischer Entwurf eines digitalen
> > Rechengeräts
> > mit mehreren asynchron laufenden Trommeln und automatischem
> > Schnellspeicherbetrieb./
> > TU Berlin, 1957 (Dissertation)) - and: Fritz-Rudolf Güntsch later (in
> > the 1960s)
> > worked for Telefunken and was the designer of the TR 4 and the TR 440 :-)
> >
> > Kind regards
> >
> > Bernd
> >
> >
> >
> > Am 16.11.2020 um 20:46 schrieb Seymour J Metz:
> > > Faster than Atlas?
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > > http://mason.gmu.edu/~smetz3
> > >
> > >
> > > 
> > > From: IBM Mainframe Discussion List  on
> > behalf of Bernd Oppolzer 
> > > Sent: Sunday, November 15, 2020 5:43 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Improve OMVS cp performance?
> > >
> > > Telefunken TR 4, designed 1958, first delivered in 1962. This predates
> > > IBM/360
> > > by at least 4 years. The fastest mainframe built in Europe at that
> time.
> > > The internal code ("Zentralcode") was an 8-bit code using 256
> characters.
> > > Word structure, a word had 48 bits plus 2 tag bits (tagged
> architecture)
> > > plus some parity bits, not seen by the programmer.
> > > Mostly used with ALGOL; the TR 4 was "a Hardware implementation of
> ALGOL"
> > > (quote from E.J. Dijkstra).
> > > A word could hold up to six characters, but some later languages
> > > (like Fortran) decided to store only 4 characters in one word,
> > > to be more compatible with IBM Fortran.
> > >
> > > Kind regards
> > >
> > > Bernd
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Wayne V. Bickerdike
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN 

Sequence or procedure of getting new dasd

[Peter]

Hello,

I am just trying to understand on how new pool of volume is created in DS8K
box , then what values are shared from DS8K with zOS system programmer to
the newly created LCU in IODF ?

Does the newly added DASD UCB needs a POR or just soft activation of IODF
holds good or we need a IPL ?

Any advise are much appreciated

Peter

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

Re: FTP converting between UTF-8 and EBCDIC

[Wayne Bickerdike]

I use iconv too. Had to jump through some hoops to get ASCII event binds to
new environments.

I use something along the lines of iconv -f IBM-1047 -t ISO8859 FIX1 > $5

This is done after a sed command to do some string conversion..

On Tue, Nov 17, 2020 at 11:06 AM Cameron Conacher 
wrote:

> You could send it in binary and then use iconv to transform to EBCDIC.
>
> Sent from my iPhone
>
> > On Nov 16, 2020, at 4:27 PM, Frank Swarbrick <
> frank.swarbr...@outlook.com> wrote:
> >
> > Originally (current production mode) there is no SBDATACONN/MBDATACONN
> specified, so z/OS is not treating the file as UTF-8.  It works fine when
> we specify "site mbdataconn=(ibm-1140,utf-8) encoding=mbcs".
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of Charles Mills 
> > Sent: Monday, November 16, 2020 2:14 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Re: FTP converting between UTF-8 and EBCDIC
> >
> > If you tell FTP that the non-EBCDIC file is UTF-8 then FTP *should*
> convert
> > accented characters and such to EBCDIC SUB (X'3F') rather than to two
> bytes.
> > Should. YMMV.
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Frank Swarbrick
> > Sent: Monday, November 16, 2020 10:16 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: FTP converting between UTF-8 and EBCDIC
> >
> > The record is made up of multiple fixed-length fields.  I guess the
> field in
> > question technically didn't overflow.  But rather it "expanded" the
> field by
> > one byte, pushing every other field one byte to the right.  Likely the
> > program that creates the file is treating the "field length" as the
> number
> > of characters, rather than the number of bytes.  I've actually asked
> them to
> > create the file as ISO-8859-1 instead of UTF-8, and if they're
> willing/able
> > to do that then this entire discussion is moot.  But I wanted to have
> this
> > as a backup solution.
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of
> > Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> > Sent: Monday, November 16, 2020 10:55 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU 
> > Subject: Re: FTP converting between UTF-8 and EBCDIC
> >
> >> On Mon, 16 Nov 2020 17:26:12 +, Frank Swarbrick wrote:
> >>
> >> Yes, it "overflowed" a fixed-length field.  x'C3A1' in the source file
> was
> > treated as two separate "ASCII" characters, x'C3' and x'A1'.  Since those
> > don't exist in the EBCDIC code page I am using they just get converted to
> > two "nonsense" characters.
> >>
> > How wide is that field?  You must have been on the bitter edge of the
> limit.
> > What happens if a client enters an actual surname exceeding the limit?
> >
> >> I agree that ideally the input source would restrict the input.  But
> since
> > that's on another team, and this workaround is likely "good enough",
> that's
> > probably unlikely to happen.
> >>
> > What was the workaround you chose, converting to which EBCDIC CCSID?
> > Is there no possibility of a client's entering a character not in that
> > CCSID?
> > What happens if someone does?  Can you fuzz test or would that intrude
> > "on another team"?
> >
> > I'd expect you need to do some filtering, perhaps to preclude SQL
> injection
> > downstream.  But that might be achieved by encoding.
> >
> > (I guessed wrong: "á", not  "â".  Spellcheck flags both.)
> >
> > -- 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
> >
> > --
> > 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
>


-- 
Wayne V. Bickerdike

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

Re: Improve OMVS cp performance?

[Wayne Bickerdike]

Atlas rang a bell and then I remembered it was used at the Rutherford labs
in Chilton.

I worked at AERE (Atomic Energy Research Establishment) which was next
door. They were basically the same campus but AERE was secure and
Rutherford wasn't.

Ferranti sold two other Atlas installations, one to a joint consortium
of London
University  and British
Petroleum  in 1963, and
another to the Atomic Energy Research Establishment
 (Harwell)
in December 1964. The AEA machine was later moved to the Atlas Computer
Laboratory at Chilton, a few yards outside the boundary fence of Harwell,
which placed it on civilian lands and thus much easier to access. This
installation grew to be the largest Atlas, containing 48 kWords of 48-bit core
memory  and 32 tape drives.

Funny story:

Somebody stole a lathe from the Rutherford labs (c. 1968). After that
happened they installed a gate and security guards at the lab.

At Harwell, we were checked for ID on entry, at Rutherford you were checked
for lathes on exit!




On Tue, Nov 17, 2020 at 8:42 AM Bernd Oppolzer 
wrote:

> Well, I didn't know much about Atlas until now, so I had to do some
> research;
> very impressive, indeed. Atlas is about 3 to 5 times faster than the TR 4.
> But in contrast to Atlas, the TR 4 was produced in a sort of small
> industrial series (35 machines);
> Atlas seems to be a super computer with very few installations.
>
> What strikes me most are the similarities:
>
> - 48 bit words
> - two 24 bit signed integers or six 8 bit-bytes or one 48 bit integer or
> floating point
> - or one instruction (two on TR 4 / TR 440)
> - 24 bit address space (only 16 on the TR 4, later 22 on the TR 440)
> - 16 k words of core store (32 k max on TR 4, 192 k words on the TR 440,
> maybe more)
> - 8 k words of read only memory for supervisor etc. (4 k on TR 4,
> nothing on TR 440,
> was loaded at startup time)
>
> Atlas was the first implementation of virtual memory,
> but the first paper on virtual memory is from Fritz-Rudolf Güntsch from
> 1957
> https://de.wikipedia.org/wiki/Fritz-Rudolf_G%C3%BCntsch -
> German wikipedia says: Güntsch is the inventor of virtual memory
> (German title: F.-R. Güntsch: /Logischer Entwurf eines digitalen
> Rechengeräts
> mit mehreren asynchron laufenden Trommeln und automatischem
> Schnellspeicherbetrieb./
> TU Berlin, 1957 (Dissertation)) - and: Fritz-Rudolf Güntsch later (in
> the 1960s)
> worked for Telefunken and was the designer of the TR 4 and the TR 440 :-)
>
> Kind regards
>
> Bernd
>
>
>
> Am 16.11.2020 um 20:46 schrieb Seymour J Metz:
> > Faster than Atlas?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of Bernd Oppolzer 
> > Sent: Sunday, November 15, 2020 5:43 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Improve OMVS cp performance?
> >
> > Telefunken TR 4, designed 1958, first delivered in 1962. This predates
> > IBM/360
> > by at least 4 years. The fastest mainframe built in Europe at that time.
> > The internal code ("Zentralcode") was an 8-bit code using 256 characters.
> > Word structure, a word had 48 bits plus 2 tag bits (tagged architecture)
> > plus some parity bits, not seen by the programmer.
> > Mostly used with ALGOL; the TR 4 was "a Hardware implementation of ALGOL"
> > (quote from E.J. Dijkstra).
> > A word could hold up to six characters, but some later languages
> > (like Fortran) decided to store only 4 characters in one word,
> > to be more compatible with IBM Fortran.
> >
> > Kind regards
> >
> > Bernd
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: FTP converting between UTF-8 and EBCDIC

[Cameron Conacher]

You could send it in binary and then use iconv to transform to EBCDIC.

Sent from my iPhone

> On Nov 16, 2020, at 4:27 PM, Frank Swarbrick  
> wrote:
> 
> Originally (current production mode) there is no SBDATACONN/MBDATACONN 
> specified, so z/OS is not treating the file as UTF-8.  It works fine when we 
> specify "site mbdataconn=(ibm-1140,utf-8) encoding=mbcs".
> 
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Charles Mills 
> Sent: Monday, November 16, 2020 2:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: FTP converting between UTF-8 and EBCDIC
> 
> If you tell FTP that the non-EBCDIC file is UTF-8 then FTP *should* convert
> accented characters and such to EBCDIC SUB (X'3F') rather than to two bytes.
> Should. YMMV.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Frank Swarbrick
> Sent: Monday, November 16, 2020 10:16 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FTP converting between UTF-8 and EBCDIC
> 
> The record is made up of multiple fixed-length fields.  I guess the field in
> question technically didn't overflow.  But rather it "expanded" the field by
> one byte, pushing every other field one byte to the right.  Likely the
> program that creates the file is treating the "field length" as the number
> of characters, rather than the number of bytes.  I've actually asked them to
> create the file as ISO-8859-1 instead of UTF-8, and if they're willing/able
> to do that then this entire discussion is moot.  But I wanted to have this
> as a backup solution.
> 
> 
> From: IBM Mainframe Discussion List  on behalf of
> Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> Sent: Monday, November 16, 2020 10:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: FTP converting between UTF-8 and EBCDIC
> 
>> On Mon, 16 Nov 2020 17:26:12 +, Frank Swarbrick wrote:
>> 
>> Yes, it "overflowed" a fixed-length field.  x'C3A1' in the source file was
> treated as two separate "ASCII" characters, x'C3' and x'A1'.  Since those
> don't exist in the EBCDIC code page I am using they just get converted to
> two "nonsense" characters.
>> 
> How wide is that field?  You must have been on the bitter edge of the limit.
> What happens if a client enters an actual surname exceeding the limit?
> 
>> I agree that ideally the input source would restrict the input.  But since
> that's on another team, and this workaround is likely "good enough", that's
> probably unlikely to happen.
>> 
> What was the workaround you chose, converting to which EBCDIC CCSID?
> Is there no possibility of a client's entering a character not in that
> CCSID?
> What happens if someone does?  Can you fuzz test or would that intrude
> "on another team"?
> 
> I'd expect you need to do some filtering, perhaps to preclude SQL injection
> downstream.  But that might be achieved by encoding.
> 
> (I guessed wrong: "á", not  "â".  Spellcheck flags both.)
> 
> -- 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
> 
> --
> 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: Improve OMVS cp performance?

[Bernd Oppolzer]

Well, I didn't know much about Atlas until now, so I had to do some 
research;

very impressive, indeed. Atlas is about 3 to 5 times faster than the TR 4.
But in contrast to Atlas, the TR 4 was produced in a sort of small 
industrial series (35 machines);

Atlas seems to be a super computer with very few installations.

What strikes me most are the similarities:

- 48 bit words
- two 24 bit signed integers or six 8 bit-bytes or one 48 bit integer or 
floating point

- or one instruction (two on TR 4 / TR 440)
- 24 bit address space (only 16 on the TR 4, later 22 on the TR 440)
- 16 k words of core store (32 k max on TR 4, 192 k words on the TR 440, 
maybe more)
- 8 k words of read only memory for supervisor etc. (4 k on TR 4, 
nothing on TR 440,

was loaded at startup time)

Atlas was the first implementation of virtual memory,
but the first paper on virtual memory is from Fritz-Rudolf Güntsch from 
1957

https://de.wikipedia.org/wiki/Fritz-Rudolf_G%C3%BCntsch -
German wikipedia says: Güntsch is the inventor of virtual memory
(German title: F.-R. Güntsch: /Logischer Entwurf eines digitalen 
Rechengeräts
mit mehreren asynchron laufenden Trommeln und automatischem 
Schnellspeicherbetrieb./
TU Berlin, 1957 (Dissertation)) - and: Fritz-Rudolf Güntsch later (in 
the 1960s)

worked for Telefunken and was the designer of the TR 4 and the TR 440 :-)

Kind regards

Bernd



Am 16.11.2020 um 20:46 schrieb Seymour J Metz:

Faster than Atlas?


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



From: IBM Mainframe Discussion List  on behalf of Bernd 
Oppolzer 
Sent: Sunday, November 15, 2020 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

Telefunken TR 4, designed 1958, first delivered in 1962. This predates
IBM/360
by at least 4 years. The fastest mainframe built in Europe at that time.
The internal code ("Zentralcode") was an 8-bit code using 256 characters.
Word structure, a word had 48 bits plus 2 tag bits (tagged architecture)
plus some parity bits, not seen by the programmer.
Mostly used with ALGOL; the TR 4 was "a Hardware implementation of ALGOL"
(quote from E.J. Dijkstra).
A word could hold up to six characters, but some later languages
(like Fortran) decided to store only 4 characters in one word,
to be more compatible with IBM Fortran.

Kind regards

Bernd



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

Re: FTP converting between UTF-8 and EBCDIC

[Frank Swarbrick]

Originally (current production mode) there is no SBDATACONN/MBDATACONN 
specified, so z/OS is not treating the file as UTF-8.  It works fine when we 
specify "site mbdataconn=(ibm-1140,utf-8) encoding=mbcs".


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Monday, November 16, 2020 2:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP converting between UTF-8 and EBCDIC

If you tell FTP that the non-EBCDIC file is UTF-8 then FTP *should* convert
accented characters and such to EBCDIC SUB (X'3F') rather than to two bytes.
Should. YMMV.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Monday, November 16, 2020 10:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP converting between UTF-8 and EBCDIC

The record is made up of multiple fixed-length fields.  I guess the field in
question technically didn't overflow.  But rather it "expanded" the field by
one byte, pushing every other field one byte to the right.  Likely the
program that creates the file is treating the "field length" as the number
of characters, rather than the number of bytes.  I've actually asked them to
create the file as ISO-8859-1 instead of UTF-8, and if they're willing/able
to do that then this entire discussion is moot.  But I wanted to have this
as a backup solution.


From: IBM Mainframe Discussion List  on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, November 16, 2020 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP converting between UTF-8 and EBCDIC

On Mon, 16 Nov 2020 17:26:12 +, Frank Swarbrick wrote:

>Yes, it "overflowed" a fixed-length field.  x'C3A1' in the source file was
treated as two separate "ASCII" characters, x'C3' and x'A1'.  Since those
don't exist in the EBCDIC code page I am using they just get converted to
two "nonsense" characters.
>
How wide is that field?  You must have been on the bitter edge of the limit.
What happens if a client enters an actual surname exceeding the limit?

>I agree that ideally the input source would restrict the input.  But since
that's on another team, and this workaround is likely "good enough", that's
probably unlikely to happen.
>
What was the workaround you chose, converting to which EBCDIC CCSID?
Is there no possibility of a client's entering a character not in that
CCSID?
What happens if someone does?  Can you fuzz test or would that intrude
"on another team"?

I'd expect you need to do some filtering, perhaps to preclude SQL injection
downstream.  But that might be achieved by encoding.

(I guessed wrong: "á", not  "â".  Spellcheck flags both.)

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

--
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 converting between UTF-8 and EBCDIC

[Charles Mills]

If you tell FTP that the non-EBCDIC file is UTF-8 then FTP *should* convert
accented characters and such to EBCDIC SUB (X'3F') rather than to two bytes.
Should. YMMV.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Frank Swarbrick
Sent: Monday, November 16, 2020 10:16 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP converting between UTF-8 and EBCDIC

The record is made up of multiple fixed-length fields.  I guess the field in
question technically didn't overflow.  But rather it "expanded" the field by
one byte, pushing every other field one byte to the right.  Likely the
program that creates the file is treating the "field length" as the number
of characters, rather than the number of bytes.  I've actually asked them to
create the file as ISO-8859-1 instead of UTF-8, and if they're willing/able
to do that then this entire discussion is moot.  But I wanted to have this
as a backup solution.


From: IBM Mainframe Discussion List  on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, November 16, 2020 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP converting between UTF-8 and EBCDIC

On Mon, 16 Nov 2020 17:26:12 +, Frank Swarbrick wrote:

>Yes, it "overflowed" a fixed-length field.  x'C3A1' in the source file was
treated as two separate "ASCII" characters, x'C3' and x'A1'.  Since those
don't exist in the EBCDIC code page I am using they just get converted to
two "nonsense" characters.
>
How wide is that field?  You must have been on the bitter edge of the limit.
What happens if a client enters an actual surname exceeding the limit?

>I agree that ideally the input source would restrict the input.  But since
that's on another team, and this workaround is likely "good enough", that's
probably unlikely to happen.
>
What was the workaround you chose, converting to which EBCDIC CCSID?
Is there no possibility of a client's entering a character not in that
CCSID?
What happens if someone does?  Can you fuzz test or would that intrude
"on another team"?

I'd expect you need to do some filtering, perhaps to preclude SQL injection
downstream.  But that might be achieved by encoding.

(I guessed wrong: "á", not  "â".  Spellcheck flags both.)

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

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

Re: Members Deleted was (Offsets SMF17)

[Charles Mills]

I *believe* the ability to defeat SMF 42 applies only to PDS, not PDSE. I 
recall that when I pitched my former product -- which monitored SMF 42 with 
real-time alerting -- that that is what I told customers.

I know you can read a PDSE directory "magically" with BSAM. I believe that 
ability is read-only. I think an attempt to open DD MY.PDSE,DISP=OLD for output 
would fail.

I don't think the PDSE API is exactly security-by-obscurity in this case. I 
would be willing to bet you that if you used the mystery API to change a PDSE 
directory -- either by purchasing the IBM documentation, or by hacking it out 
on your own -- that SMF 42 would report the change.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, November 16, 2020 10:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Members Deleted was (Offsets SMF17)

On Mon, 16 Nov 2020 10:23:57 -0800, Charles Mills wrote:

>SMF Type 42 subtypes 20 and/or 21 will give you that information: 21 for
>straight member delete, and 20 for PDSE directory re-initialize. I don't
>think type 17 is relevant to this problem.
>
>Be aware that it is possible for a malicious programmer to defeat it: if a
>program opens a PDS as a BSAM dataset and manipulates the directory directly
>that will not be reflected in SMF Type 42, although SMF 15 would show that a
>PDS was closed for xSAM output -- and there would be no corresponding SMF
>Type 42. Although I suppose it might be possible to defeat that check also.
> 
Is PDSE more robust?  I believe one can open a PDSE as a BSAM data set and
read but not write the directory directly (it fakes it?)  And IBM provides some
security-by-obscurity by concealing PDSE details (except for a high price).

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

Re: Improve OMVS cp performance?

[R.S.]

As a old computer hobbyist I've collected (very) few pictures of TR 4.
Wooden parts of cabinets, construction similar to contemporary 19" racks.
Nice machine, part of IT history.

--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: Improve OMVS cp performance?

[Seymour J Metz]

That's still wrong:

http://bitsavers.org/pdf/ibm/7030/22-6530-2_7030RefMan.pdf#page=169


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



From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab 
Sent: Sunday, November 15, 2020 4:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

Sorry.  First computer to use 8 bits per character.

On Sun, Nov 15, 2020 at 11:09 AM Seymour J Metz  wrote:
>
> > You have to remember that S/360 was the first 8 bit computer.
>
> What is the 7030, chopped liver?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Mike Schwab 
> Sent: Saturday, November 14, 2020 9:25 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Improve OMVS cp performance?
>
> You have to remember that S/360 was the first 8 bit computer.  Prior
> computers used 4 bits for a digit and 6 bits for a character.  They
> designed EBCDIC to be easily converted for use with existing 7 track
> tape drives, printers, card and tape readers and punches.  There was a
> proposed ASCII code that was put on documentation but dropped for the
> 370 virtual memory bit in the PSW.
>
> On Sat, Nov 14, 2020 at 6:39 PM Seymour J Metz  wrote:
> >
> > I doubt that IBM custumers would have been happy with an 8-bit code page 
> > with only 128 valid code points. International considerations would still 
> > have forced IBM to device incompatible code pages for different countries.
> >
> > Obviously 8859 is another Tower of Babel; why do you think I described it 
> > as "a dollar short"?
> >
> > No,, IBM could not have implemented full Unicode, or even the full MLP, 
> > back in the 1960s. But it could certainly have implemented a basic subset 
> > for all customers and selected additional pages for international 
> > customers. Had Unicode and UTF-8 been around at the time, I'm certain that 
> > IBM would have gone that route.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> >
> > 
> > From: IBM Mainframe Discussion List  on behalf of 
> > Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
> > Sent: Saturday, November 14, 2020 6:22 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Improve OMVS cp performance?
> >
> > On Sat, 14 Nov 2020 23:00:00 +, Seymour J Metz wrote:
> >
> > >Because there was no standard 8-bit code at the time. IBM did push for an 
> > >8-bit ASCII,
> > >
> > That's not an obstacle.  DEC PDP-8 stored ASCII characters one per
> > 12-bit word.  IBM could have simply declared the top bit "reserved"
> > as they are so often wont to do.
> >
> > >but it never happened except for a mapping between octets and punch 
> > >combinations on cards. Had Unicode been around at the time they would 
> > >probably have jumped at it.
> > >
> > >ISO 8859 was a day late and a dollar short.
> > >
> > ISO-8859-* is afflicted with the same babel as EBCDIC code pages
> > because of the "*" you elided.
> >
> > UTF-8 is the norm nowadays because of a peculiar upward compatibility
> > with ASCII.  But the mebibytes and megahertz to support it came a day late.
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

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

Re: Improve OMVS cp performance?

[Seymour J Metz]

> They only had 7 track tapes at the time.

Are you a betting man?


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



From: IBM Mainframe Discussion List  on behalf of 
Mike Schwab 
Sent: Sunday, November 15, 2020 5:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

They only had 7 track tapes at the time.

9 track tapes introduced with S/360 in 1964.
https://secure-web.cisco.com/15XvqSwTkb8sH4cs6M51pKSQPk3d5UMx0-OZWOJ-qVN-Xi3Em6QAF-WxBpwlIxb4H-MIL_lx-Sjm3-fYErj8-_wb3XmyqHn8YwVkyLcFpqfg5HOxgP-3u6TV5WZoS9eSBARFIPSwxXNPiVInLz7T7XfYMW8GF4xFUHfMkxEQqaugiyRJI2b-7ozMXS67SLYZdCL_GML_68jxRtZS8n1wpWPPi4_gJBf7UrHScZXtCb_mTD6A0KCSIXj79GLDoX1HfombbmMh1rWbORrUkfDCfuqb3oudoIDruIhlxDkbAP_-7tY49ZzJiT37K2xxiMe3hr2vjakbV8KMdSRC_vYHFs6DTqTkK9PhyVHfnweIZwHbdul1nV5ajaPlYlmIHw915zOZMUqtYPHHOw_GoTnqH6YimQOMHeC53GnS4KHEiXoelc3T9eAJL_QjV-RFTKdkI/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2F9_track_tape

On Sun, Nov 15, 2020 at 3:36 PM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Sun, 15 Nov 2020 15:13:24 -0600, Mike Schwab wrote:
>
> >Sorry.  First computer to use 8 bits per character.
> >
> Wikipedia, not necessarily an authority, says:
> 
> https://secure-web.cisco.com/1nkIhum4wox25jkI5iyrdaNhYiLZ-wEKIr3K4FJU0KBpoOtcfywPRSnP9jzVOX-9S8QZjIml46GxRNS1b2fKnylfTLqYAXUVsy4GHz8fzHXPRAKuVy0q0Q-ha8KLERcqzewzfdpjYIlNEbkZQ8xYjzgsF9vD3-o9FFmMk-ZeQsGyfATz-ct5fo02aXF-g0sn7_8Ax67Ftiy2kjGEiZk3yDaEs75vcK08soi_H9HBWYSZfMwEgNQ5Chi0qaI-OEaMOGvf-fNfsdgO7cGmxGOyIGst1qyQOoBzS9V1CrFsevh-h3fKH6xVuolZBz2I9ylh_gOKwSoCLhkRxeb_KPNJNUXkPHactrTwT2naYwfJdOoMoksJuj1NYmtSqNw74vRX0d7Z3Gsf0FyPEnz-J_EIEafTVDrXhAJrT7AnH2MdZC9iUY1BW9ldH5qyOiC-gCu7f/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FIBM_7030_Stretch#Data_formats
> Alphanumeric characters are variable length and can use any character 
> code of 8 bits or less.
>
> ... so, if true, 8 bits was at least possible.  Was it widely in "use"?
>
> >On Sun, Nov 15, 2020 at 11:09 AM Seymour J Metz wrote:
> >>
> >> > You have to remember that S/360 was the first 8 bit computer.
> >>
> >> What is the 7030, chopped liver?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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


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

Re: Improve OMVS cp performance?

[Seymour J Metz]

Faster than Atlas?


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



From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Sunday, November 15, 2020 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

Telefunken TR 4, designed 1958, first delivered in 1962. This predates
IBM/360
by at least 4 years. The fastest mainframe built in Europe at that time.
The internal code ("Zentralcode") was an 8-bit code using 256 characters.
Word structure, a word had 48 bits plus 2 tag bits (tagged architecture)
plus some parity bits, not seen by the programmer.
Mostly used with ALGOL; the TR 4 was "a Hardware implementation of ALGOL"
(quote from E.J. Dijkstra).
A word could hold up to six characters, but some later languages
(like Fortran) decided to store only 4 characters in one word,
to be more compatible with IBM Fortran.

Kind regards

Bernd


Am 15.11.2020 um 03:25 schrieb Mike Schwab:
> You have to remember that S/360 was the first 8 bit computer.  Prior
> computers used 4 bits for a digit and 6 bits for a character.  They
> designed EBCDIC to be easily converted for use with existing 7 track
> tape drives, printers, card and tape readers and punches.  There was a
> proposed ASCII code that was put on documentation but dropped for the
> 370 virtual memory bit in the PSW.
>

--
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: Improve OMVS cp performance?

[Seymour J Metz]

Did you ask him what he though the various distribution tapes were?  On 7-track 
tape you really don't have much choice what to use.


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



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, November 15, 2020 6:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

On Sun, 15 Nov 2020 16:28:02 -0600, Mike Schwab  wrote:

>They only had 7 track tapes at the time.
>
>9 track tapes introduced with S/360 in 1964.
>https://secure-web.cisco.com/1g3kTcng6DKLa2wZpjswahVbue_vj3uf2QkkhXiKJmCVFfYS7CwPJCOtzLp6sJGh2jwDBJtf-fQIAfhpg9JoyFjr-NP3GJ49DpgasRSaveY70zBAeUcG96cx9DjCCN7RLPVCYV0a5iunz5SDfQn5nUBPwdAzgTbqxMX_OnnnrbUL7OE0eJTsPrbRH4BSajmMRuFZmnPF6bjm9LjWZhRPwPeokTh9c_ZgD83Nr3egz_aDsyHEFvR8fWZl1pcJuZD_eSGb4o_-LVqZnSkkL72wa2225iWLTRU_R7Lmg5vfQNsInxpKROCItW2KofD7KGBQqfEte6pHmt7jYDvsPEWDAgyA4uUlhNRJ6lYNNRE6AzdSfLrBhnJIaQa1NyExfHakIOcVdnTX_c-_bwT1zHcIr9fhzdLOUcUwlKyrq_rn8c2c-w42RxSz2qvekUt_uRHN0/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2F9_track_tape
>
Which was no obstacle.  There were two modes of I/O to 7-track tapes:
TRTCH=T, which mapped each tape frame of 6 data bits
plus 1 parity to one 8-bit byte.
TRTCH=C, which mapped the 24 data bits of 4 tape frames to 3 bytes

I know; I successfully used the latter.  I had to argue with ops who tried
to tell me that I shouldn't use that; it would corrupt mu data.  It didn't.

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

Other user trying to run my shell script gets "FSUM7351 not found" error

[Frank Swarbrick]

Any thoughts on this?  I can execute this job and have no issue.  I'm trying to 
let another developer run it.  He's able to run /u/dvfjs/rocket/bin/curl 
directly (in STDPARM, following "SH ".)  But if he executes my shell script 
(/u/dvfjs/jira_test) he gets "/u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4: 
FSUM7351 not found".

I've set the read and execution bits for user, group and other for both curl 
and the jira_test shell script.  Since the "echo" commands are working for him, 
he's obviously able to execute my shell script itself.  What else might I be 
missing?  The other developer has an OMVS segment, but he doesn't have an 
initial working directory or default shell configured yet.  Could that be the 
issue?  If so, what specifically is causing this particular issue?

JCL:
//DVRJZTST JOB ,'Test',CLASS=C,REGION=0M,NOTIFY=
//*
//UNIX EXEC PGM=BPXBATCH
//STDOUT   DD SYSOUT=*
//STDERR   DD SYSOUT=*
//STDPARM  DD *
SH /u/dvfjs/jira_test
/*

/u/dvfjs/jira_test:
#!/bin/sh -x

echo **before**
/u/dvfjs/rocket/bin/curl --help
echo **after**

File attributes:
-sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/jira_test
- untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971  77 Nov 16 12:24 
/u/dvfjs/jira_test
-sh|DVFJS:/u/dvfjs:>ls -FalTHp /u/dvfjs/rocket/bin/curl
- untaggedT=off -rwxr-xr-x     1 DVFJSDEPT9971 21266432 Nov  1  
2019 /u/dvfjs/rocket/bin/curl

STDERR:
FSUM1012 The initial working directory was not specified.
FSUM1006 A shell was not specified. Processing continues using the default 
shell name.
+ echo **before**
+ /u/dvfjs/rocket/bin/curl --help
/u/dvfjs/rocket/bin/curl: /u/dvfjs/jira_test 4:
+ echo **after**

STDOUT:
**before**
**after**



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

Re: Improve OMVS cp performance?

[Bernd Oppolzer]

FWIW: the Telefunken TR4 indeed only supported half word addressing;
the half words being 24 bits; full words of 48 (plus some extra) bits 
had even adresses,
which also were the addresses of the left halfword; the right halfword 
had the address

of the left halfword plus one.

The TR 4 offspring TR 440 (which was ten times faster, a time sharing 
machine)
supported COBOL and later Multics-PL/1; and then there was the need to 
support

byte addressing, too. So some operations were added which worked
on so-called "Oktadenadressen", which were in fact halfword addresses
multiplied by 3 (you can imagine how the mapping of the byte addresses 
to the
halfword addresses worked, very similar to the IBM/360). The Telefunken 
TR 440
was developped from 1965 on and first delivered in 1969. So this was 
indeed after
IBM/360; but IIRC, the byte addressing added to the TR 440 was not 
inspired by the

360 machine - the COBOL compiler group asked for that.

I recently read some old documents about the German computer industry in 
the 1960s.
The IBM/360 announcement apparently came like a shock to Telefunken, but 
they
finally decided to keep direction, because some important customers 
asked for a

system to replace the TR 4 machine, which had been quite successful.
And German government supported and funded the development.

About 50 TR 440 machines were built, and they worked until the mid 1980s 
in Germany

(at universities). 20 Million Deutsche Marks for one machine :-)
It was no commercial success, but it motivated many people to enter the
computer business; it was much fun, after all :-)

I worked with the TR 440 at Stuttgart university from 1977 to 1981,
when I was a young student of computer science. The programming language
I used most was Pascal (and some Telefunken-ASSEMBLER).
From 1984 to 2001 ca.: Pascal/VS on IBM machines on VM/CMS :-)
Later 370-ASSEMBLER, PL/1 and C.
Today again: New Stanford Pascal - http://bernd-oppolzer.de/job9.htm

Kind regards

Bernd



Am 16.11.2020 um 09:28 schrieb Timothy Sipples:

Mike Schwab wrote:

You have to remember that S/360 was the first 8 bit computer.
[]
Sorry.  First computer to use 8 bits per character.

I see others have cited the IBM 7030 and Telefunken TR 4 as examples of
early computers that used (or at least were explicitly engineered to use)
8 bit character encoding. However, as far as I can tell both of those
machines were word addressable machines, and their word sizes were
different and much larger than their character sizes. Was there any
pre-System/360 example of a computer that stored characters in 8 bits
*and* offered 8 bit memory addressing? (Or 6 and 6, or 7 and 7?) For that
matter, are there any still extant digital computer processors that (only)
have word addressable memory and don't have 8 bit byte addressable memory?

History evidently judges that particular System/360 design decision as
wise or at least not unwise.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
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: Members Deleted was (Offsets SMF17)

[Paul Gilmartin]

On Mon, 16 Nov 2020 10:23:57 -0800, Charles Mills wrote:

>SMF Type 42 subtypes 20 and/or 21 will give you that information: 21 for
>straight member delete, and 20 for PDSE directory re-initialize. I don't
>think type 17 is relevant to this problem.
>
>Be aware that it is possible for a malicious programmer to defeat it: if a
>program opens a PDS as a BSAM dataset and manipulates the directory directly
>that will not be reflected in SMF Type 42, although SMF 15 would show that a
>PDS was closed for xSAM output -- and there would be no corresponding SMF
>Type 42. Although I suppose it might be possible to defeat that check also.
> 
Is PDSE more robust?  I believe one can open a PDSE as a BSAM data set and
read but not write the directory directly (it fakes it?)  And IBM provides some
security-by-obscurity by concealing PDSE details (except for a high price).

-- gil

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

Re: Members Deleted was (Offsets SMF17)

[Charles Mills]

SMF Type 42 subtypes 20 and/or 21 will give you that information: 21 for
straight member delete, and 20 for PDSE directory re-initialize. I don't
think type 17 is relevant to this problem.

Be aware that it is possible for a malicious programmer to defeat it: if a
program opens a PDS as a BSAM dataset and manipulates the directory directly
that will not be reflected in SMF Type 42, although SMF 15 would show that a
PDS was closed for xSAM output -- and there would be no corresponding SMF
Type 42. Although I suppose it might be possible to defeat that check also.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Steely.Mark
Sent: Monday, November 16, 2020 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Members Deleted was (Offsets SMF17)

At one time did IBM says that SMF reporting would also be done at the member
level. I need to find the date, time & ID  a member was deleted. 

If this is the case does anyone have a process to do this. 

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

Re: FTP converting between UTF-8 and EBCDIC

[Frank Swarbrick]

The record is made up of multiple fixed-length fields.  I guess the field in 
question technically didn't overflow.  But rather it "expanded" the field by 
one byte, pushing every other field one byte to the right.  Likely the program 
that creates the file is treating the "field length" as the number of 
characters, rather than the number of bytes.  I've actually asked them to 
create the file as ISO-8859-1 instead of UTF-8, and if they're willing/able to 
do that then this entire discussion is moot.  But I wanted to have this as a 
backup solution.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, November 16, 2020 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP converting between UTF-8 and EBCDIC

On Mon, 16 Nov 2020 17:26:12 +, Frank Swarbrick wrote:

>Yes, it "overflowed" a fixed-length field.  x'C3A1' in the source file was 
>treated as two separate "ASCII" characters, x'C3' and x'A1'.  Since those 
>don't exist in the EBCDIC code page I am using they just get converted to two 
>"nonsense" characters.
>
How wide is that field?  You must have been on the bitter edge of the limit.
What happens if a client enters an actual surname exceeding the limit?

>I agree that ideally the input source would restrict the input.  But since 
>that's on another team, and this workaround is likely "good enough", that's 
>probably unlikely to happen.
>
What was the workaround you chose, converting to which EBCDIC CCSID?
Is there no possibility of a client's entering a character not in that CCSID?
What happens if someone does?  Can you fuzz test or would that intrude
"on another team"?

I'd expect you need to do some filtering, perhaps to preclude SQL injection
downstream.  But that might be achieved by encoding.

(I guessed wrong: "á", not  "â".  Spellcheck flags both.)

-- 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: Members Deleted was (Offsets SMF17)

[Sri h Kolusu]

> At one time did IBM says that SMF reporting would also be done at
> the member level. I need to find the date, time & ID  a member was
deleted.
>

Mark,

For member deletions you need to extract TYPE 42 and sub-type 21

Subtype 21 is written when a member is deleted from a PDS or a PDSE to
indicate who or what (job, started task, or TSO user) deleted the member.
It contains the name of the data set and the volume serial of the volume on
which it resided, including all the aliases of the member that fits in the
SMF record.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieag200/rec42.htm

So use the following JCL

//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD DISP=SHR,DSN=Your SMF dataset
//SORTOUT  DD SYSOUT=*
//SYSINDD *
  OPTION COPY,VLSCMP
  INCLUDE COND=(06,01,BI,EQ,42,AND,  $ TYPE 42
23,02,BI,EQ,21)  $ SUBTYPE 21
/*


Further if you have any questions please let me know

Thanks,
Kolusu
DFSORT Development
IBM Corporation



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

Members Deleted was (Offsets SMF17)

[Steely.Mark]

At one time did IBM says that SMF reporting would also be done at the member 
level. I need to find the date, time & ID  a member was deleted.

If this is the case does anyone have a process to do this.

Thank You

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Sri 
h Kolusu
Sent: Friday, November 06, 2020 10:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Offsets SMF17

ATTENTION: This e-mail came from an external source. Do not open attachments or 
click on links from unknown or unexpected emails.


> I want to make a list of the files that have been deleted, from SMF
> record 17, and it must be offsets but nothing comes out.
> can you help me?


Jordi,

As others mentioned, your offsets are off.  SMF17 layout is pretty straight 
forward. So you can code DFSORT symbols and use them instead of hard coding the 
offsets. So use the following job

//STEP1EXEC PGM=ICETOOL
//TOOLMSG  DD SYSOUT=*
//DFSMSG   DD SYSOUT=*
//SYMNOUT  DD SYSOUT=*
//SYMNAMES DD *
SMF17RDW,1,04,BI
  SMF17LEN,=,02,BI
  SMF17SEG,*,02,BI
SMF17FLG,*,01,BI
SMF17RTY,*,01,BI
SMF17TME,*,04,BI
SMF17DTE,*,04,PD
SMF17SID,*,04,CH
SMF17JBN,*,08,CH
SMF17RST,*,04,BI
SMF17RSD,*,04,PD
SMF17UID,*,08,CH
SMF17RIN,*,02,BI
SMF17DSN,*,44,CH
 SMF17DSNF,=,04,CH
 SMF17DSNR,*,40,CH
SMF17RV1,*,03,BI
SMF17NVL,*,01,BI
SMF17RV2,*,02,BI
SMF17FVL,*,06,CH
/*
//RAWSMF   DD DISP=SHR,DSN=SA$SF.ALL.M.GEN1.YEAR2011.DATA.G0001V00
// DD DISP=SHR,DSN=SA$SF.ALL.M.GEN1.YEAR2011.DATA.G0002V00
// DD DISP=SHR,DSN=SA$SF.ALL.M.GEN1.YEAR2011.DATA.G0003V00
// DD DISP=SHR,DSN=SA$SF.ALL.M.GEN1.YEAR2011.DATA.G0004V00
//SMF  DD DSN=&,SPACE=(CYL,(15,15)),UNIT=SYSDA
//SMFREP   DD DSN=SA80855.GENX.SMF17.TXT,
//UNIT=3390,DISP=(,CATLG),
//SPACE=(CYL,(2,2),RLSE)
//TOOLIN   DD *
  COPY FROM(RAWSMF) TO(SMF) USING(SMFI)
  DISPLAY FROM(SMF) LIST(SMFREP) -
  BETWEEN(2) -
  LINES(999) -
  BLANK  -
  TITLE('SMF-17 : WHO DELETED DATASETS') DATE TIME PAGE  -
  HEADER('SMF')   ON(SMF17RTY)   -
  HEADER('SYS')   ON(SMF17SID)   -
  HEADER('DATE')  ON(SMF17DTE,DT1,E'/99/99') -
  HEADER('TIME')  ON(SMF17TME,TM1,E'99:99:99')   -
  HEADER('JOB')   ON(SMF17JBN)   -
  HEADER('USER')  ON(SMF17UID)   -
  HEADER('DATASET DELETED') ON(SMF17DSN) -
  HEADER('-VOLS') ON(SMF17NVL)   -
  HEADER('VOLSER') ON(SMF17FVL)
/*
//SMFICNTL DD *
  OPTION VLSCMP,SPANINC=RC0
  INCLUDE COND=(SMF17RTY,EQ,17,AND,  $ TYPE 17
SMF17DSN,EQ,C'UCAT')  $ SMF17DSN = UCAT

  SORT FIELDS=(SMF17DTE,A,   $ SMF17DTE
   SMF17TME,A)   $ SMF17TME
/*


Just in case the format is messed up here, I am going to send the solution as a 
text mail offline.

Thanks,
Kolusu
DFSORT Development
IBM Corporation



--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
*** Disclaimer ***
This communication (including all attachments) is solely for the use of the 
person to whom it is addressed and is a confidential AAA communication. If you 
are not the intended recipient, any use, distribution, printing, or copying is 
prohibited. If you received this email in error, please immediately delete it 
and notify the sender.

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

Re: FTP converting between UTF-8 and EBCDIC

[Paul Gilmartin]

On Mon, 16 Nov 2020 17:26:12 +, Frank Swarbrick wrote:

>Yes, it "overflowed" a fixed-length field.  x'C3A1' in the source file was 
>treated as two separate "ASCII" characters, x'C3' and x'A1'.  Since those 
>don't exist in the EBCDIC code page I am using they just get converted to two 
>"nonsense" characters.
> 
How wide is that field?  You must have been on the bitter edge of the limit.
What happens if a client enters an actual surname exceeding the limit?

>I agree that ideally the input source would restrict the input.  But since 
>that's on another team, and this workaround is likely "good enough", that's 
>probably unlikely to happen.
>
What was the workaround you chose, converting to which EBCDIC CCSID?
Is there no possibility of a client's entering a character not in that CCSID?
What happens if someone does?  Can you fuzz test or would that intrude
"on another team"?

I'd expect you need to do some filtering, perhaps to preclude SQL injection
downstream.  But that might be achieved by encoding.

(I guessed wrong: "á", not  "â".  Spellcheck flags both.)

-- gil

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

Re: FTP converting between UTF-8 and EBCDIC

[Frank Swarbrick]

Yes, it "overflowed" a fixed-length field.  x'C3A1' in the source file was 
treated as two separate "ASCII" characters, x'C3' and x'A1'.  Since those don't 
exist in the EBCDIC code page I am using they just get converted to two 
"nonsense" characters.

I agree that ideally the input source would restrict the input.  But since 
that's on another team, and this workaround is likely "good enough", that's 
probably unlikely to happen.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, November 15, 2020 8:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: FTP converting between UTF-8 and EBCDIC

On Mon, 16 Nov 2020 02:28:06 +, Frank Swarbrick wrote:

>We don't use Unix for any of our production business applications.  If we were 
>"starting from scratch" I imagine we might choose to use Unix files for many 
>things, but I can't see us going this direction now.
>
>This is an existing process with an existing MVS data set, and up until a 
>couple of days ago it was treated (on the remote side) as just a standard 
>"ASCII" file.   A couple of days ago a user entered as last name with a 
>lower-case 'a' with an accent, causing a two-byte character to be used where 
>it had always been a single byte before.  
>
Did that (â?) cause the last name to overflow a field?  If not, what's the 
problem?

No single SBCS code page can accommodate all characters you're likely to 
encounter.

You might filter on input to acceptable, SBCS-translatable characters.
Expect accusations of ethnic bias if you do that.

-- 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: Need some help with SSL error

[Edgington, Jerry]

Thanks everyone how responded.  We have fixed this issue. The problem was the 
AT/TLS definition, we had two RULES with the different parms and the secondary 
one was higher priority than the first.  So, only the secondary rule was taking 
effect and passing the wrong SSL certificate to the client.

Thanks again,
Jerry 

-Original Message-
From: Edgington, Jerry 
Sent: Monday, November 16, 2020 10:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RE: Need some help with SSL error


We have tracing in AT/TLS turned on, but nothing in the trace for these 
connections.  So, I don't believe it is AT/TLS, otherwise there should have 
been some trace entries.

EZZ6034I TN3270 CONN 1F4F LU **N/A**  CONN DROP  ERR 100B 463
  IP..PORT: :::xx.xx.xx.xx..56968  EZBTTRCV

I am looking to trace to TCPIP for that specific IP address.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Edgington, Jerry
Sent: Monday, November 16, 2020 9:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need some help with SSL error

Thanks Keith, and the only error messages was this:

>> M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270
>> CONN 025C LU **N/A**  CONN DROP  ERR 100B 864
>> E 864 0090IP..PORT:
>> :::xx.xx.xx.xx..53084 EZBTTRCV

And I am working on changing the TTLSConnectionAction to CtraceClearText(ON) 
and Trace(254).  

Jerry 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Keith Gooding
Sent: Monday, November 16, 2020 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need some help with SSL error

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


Did you get any messages from AT-TLS  (prefix EZY) ?. Trace level 7 should 
cause error messages to appear on the job log in addition to the unix syslog. 
Maybe the rule is not being triggered. If you are able to increase the trace 
level to 31 you should be able to see what System SSL options were set by 
At-Tls (if the rule was triggered) . The debug messages are sent to syslogd. .

Keith Gooding 

> On 16 Nov 2020, at 14:24, Joe Monk  wrote:
> 
> Error 100B:
> 
> 100B Unexpected SSL handshake encountered.An SSL handshake header was 
> encountered on a basic port or the client immediately entered an SSL 
> handshake for a CONNTYPE option value other than SECURE or ANY. Verify 
> that the client and port settings are compatible.
> A quick google found this:
> 
> https://www.ibm.com/support/pages/zos-communications-server-tls-needed
> -implement-tls-v12
> 
> Joe
> 
> 
> 
> 
>> On Mon, Nov 16, 2020 at 6:27 AM Edgington, Jerry < 
>> jerry.edging...@westernsouthernlife.com> wrote:
>> 
>> I need some help, please.  We have an automated system, using TN3270 
>> screen scraping.  Over the weekend, we IPL'ed, first time in April,
>> 2020 and now, when this "automated" system/client tries to connect 
>> over TN3270, we are getting this error message:
>> 
>> M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270
>> CONN 025C LU **N/A**  CONN DROP  ERR 100B 864
>> E 864 0090IP..PORT:
>> :::xx.xx.xx.xx..53084 EZBTTRCV
>> 
>> The AT/TLS policy has changed since August, 2020.  And we only have 
>> TLS
>> v1.2 turned on for only specific inbound IP addresses.  We are 
>> running z/OS v2.1, at this point
>> 
>> Any suggestions, help or ideas, would be great.
>> 
>> Thanks,
>> Jerry Edgington
>> 
>> Here is the AT/TLS policy. I have masked the names for security reasons.
>> ##---
>> ## Rules for yyy servers using xx IP over port 923
>> ##---
>> TTLSRule  yyy-xx-SSL
>> {
>>  LocalAddrGroupRef x-Ip-Addr
>>  RemoteAddrGroupRef   yyy-Server-IpAddr
>>  LocalPortRange 923
>>  RemotePortRangeRef Port-Remote
>>  Direction Inbound
>>  Priority500
>>  TTLSGroupActionRef   gAct1
>>  TTLSEnvironmentActionRefeAct1
>>  TTLSConnectionActionRef cAct-x
>> }
>> 
>> TTLSConnectionAction  cAct-x
>> {
>>  HandshakeRole Server
>>  TTLSCipherParmsRef   cipher1~Default_Ciphers
>>  TTLSConnectionAdvancedParmsRef  cAdv-xx
>>  CtraceClearText Off
>>  Trace7
>> }
>> 
>> 

Re: Need some help with SSL error

[Edgington, Jerry]

We have tracing in AT/TLS turned on, but nothing in the trace for these 
connections.  So, I don't believe it is AT/TLS, otherwise there should have 
been some trace entries.

EZZ6034I TN3270 CONN 1F4F LU **N/A**  CONN DROP  ERR 100B 463
  IP..PORT: :::xx.xx.xx.xx..56968  EZBTTRCV

I am looking to trace to TCPIP for that specific IP address.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Edgington, Jerry
Sent: Monday, November 16, 2020 9:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need some help with SSL error

Thanks Keith, and the only error messages was this:

>> M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270
>> CONN 025C LU **N/A**  CONN DROP  ERR 100B 864
>> E 864 0090IP..PORT:
>> :::xx.xx.xx.xx..53084 EZBTTRCV

And I am working on changing the TTLSConnectionAction to CtraceClearText(ON) 
and Trace(254).  

Jerry 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Keith Gooding
Sent: Monday, November 16, 2020 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need some help with SSL error

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


Did you get any messages from AT-TLS  (prefix EZY) ?. Trace level 7 should 
cause error messages to appear on the job log in addition to the unix syslog. 
Maybe the rule is not being triggered. If you are able to increase the trace 
level to 31 you should be able to see what System SSL options were set by 
At-Tls (if the rule was triggered) . The debug messages are sent to syslogd. .

Keith Gooding 

> On 16 Nov 2020, at 14:24, Joe Monk  wrote:
> 
> Error 100B:
> 
> 100B Unexpected SSL handshake encountered.An SSL handshake header was 
> encountered on a basic port or the client immediately entered an SSL 
> handshake for a CONNTYPE option value other than SECURE or ANY. Verify 
> that the client and port settings are compatible.
> A quick google found this:
> 
> https://www.ibm.com/support/pages/zos-communications-server-tls-needed
> -implement-tls-v12
> 
> Joe
> 
> 
> 
> 
>> On Mon, Nov 16, 2020 at 6:27 AM Edgington, Jerry < 
>> jerry.edging...@westernsouthernlife.com> wrote:
>> 
>> I need some help, please.  We have an automated system, using TN3270 
>> screen scraping.  Over the weekend, we IPL'ed, first time in April,
>> 2020 and now, when this "automated" system/client tries to connect 
>> over TN3270, we are getting this error message:
>> 
>> M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270
>> CONN 025C LU **N/A**  CONN DROP  ERR 100B 864
>> E 864 0090IP..PORT:
>> :::xx.xx.xx.xx..53084 EZBTTRCV
>> 
>> The AT/TLS policy has changed since August, 2020.  And we only have 
>> TLS
>> v1.2 turned on for only specific inbound IP addresses.  We are 
>> running z/OS v2.1, at this point
>> 
>> Any suggestions, help or ideas, would be great.
>> 
>> Thanks,
>> Jerry Edgington
>> 
>> Here is the AT/TLS policy. I have masked the names for security reasons.
>> ##---
>> ## Rules for yyy servers using xx IP over port 923
>> ##---
>> TTLSRule  yyy-xx-SSL
>> {
>>  LocalAddrGroupRef x-Ip-Addr
>>  RemoteAddrGroupRef   yyy-Server-IpAddr
>>  LocalPortRange 923
>>  RemotePortRangeRef Port-Remote
>>  Direction Inbound
>>  Priority500
>>  TTLSGroupActionRef   gAct1
>>  TTLSEnvironmentActionRefeAct1
>>  TTLSConnectionActionRef cAct-x
>> }
>> 
>> TTLSConnectionAction  cAct-x
>> {
>>  HandshakeRole Server
>>  TTLSCipherParmsRef   cipher1~Default_Ciphers
>>  TTLSConnectionAdvancedParmsRef  cAdv-xx
>>  CtraceClearText Off
>>  Trace7
>> }
>> 
>> TTLSConnectionAdvancedParms   cAdv-
>> {
>>  HandshakeTimeout 30
>>  CertificateLabel ATTLS
>>  SecondaryMap  Off
>>  TLSv1.2On
>>  ApplicationControlled  On
>> }
>> 
>> TTLSEnvironmentAction eAct1
>> {
>>  HandshakeRole Server
>>  EnvironmentUserInstance 0
>>  TTLSKeyringParmsRef keyR~ZOS112
>> }

Re: Need some help with SSL error

[Edgington, Jerry]

Thanks Keith, and the only error messages was this:

>> M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270
>> CONN 025C LU **N/A**  CONN DROP  ERR 100B 864
>> E 864 0090IP..PORT:
>> :::xx.xx.xx.xx..53084 EZBTTRCV

And I am working on changing the TTLSConnectionAction to CtraceClearText(ON) 
and Trace(254).  

Jerry 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Keith Gooding
Sent: Monday, November 16, 2020 9:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need some help with SSL error

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


Did you get any messages from AT-TLS  (prefix EZY) ?. Trace level 7 should 
cause error messages to appear on the job log in addition to the unix syslog. 
Maybe the rule is not being triggered. If you are able to increase the trace 
level to 31 you should be able to see what System SSL options were set by 
At-Tls (if the rule was triggered) . The debug messages are sent to syslogd. .

Keith Gooding 

> On 16 Nov 2020, at 14:24, Joe Monk  wrote:
> 
> Error 100B:
> 
> 100B Unexpected SSL handshake encountered.An SSL handshake header was 
> encountered on a basic port or the client immediately entered an SSL 
> handshake for a CONNTYPE option value other than SECURE or ANY. Verify 
> that the client and port settings are compatible.
> A quick google found this:
> 
> https://www.ibm.com/support/pages/zos-communications-server-tls-needed
> -implement-tls-v12
> 
> Joe
> 
> 
> 
> 
>> On Mon, Nov 16, 2020 at 6:27 AM Edgington, Jerry < 
>> jerry.edging...@westernsouthernlife.com> wrote:
>> 
>> I need some help, please.  We have an automated system, using TN3270 
>> screen scraping.  Over the weekend, we IPL'ed, first time in April, 
>> 2020 and now, when this "automated" system/client tries to connect 
>> over TN3270, we are getting this error message:
>> 
>> M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270
>> CONN 025C LU **N/A**  CONN DROP  ERR 100B 864
>> E 864 0090IP..PORT:
>> :::xx.xx.xx.xx..53084 EZBTTRCV
>> 
>> The AT/TLS policy has changed since August, 2020.  And we only have 
>> TLS
>> v1.2 turned on for only specific inbound IP addresses.  We are 
>> running z/OS v2.1, at this point
>> 
>> Any suggestions, help or ideas, would be great.
>> 
>> Thanks,
>> Jerry Edgington
>> 
>> Here is the AT/TLS policy. I have masked the names for security reasons.
>> ##---
>> ## Rules for yyy servers using xx IP over port 923
>> ##---
>> TTLSRule  yyy-xx-SSL
>> {
>>  LocalAddrGroupRef x-Ip-Addr
>>  RemoteAddrGroupRef   yyy-Server-IpAddr
>>  LocalPortRange 923
>>  RemotePortRangeRef Port-Remote
>>  Direction Inbound
>>  Priority500
>>  TTLSGroupActionRef   gAct1
>>  TTLSEnvironmentActionRefeAct1
>>  TTLSConnectionActionRef cAct-x
>> }
>> 
>> TTLSConnectionAction  cAct-x
>> {
>>  HandshakeRole Server
>>  TTLSCipherParmsRef   cipher1~Default_Ciphers
>>  TTLSConnectionAdvancedParmsRef  cAdv-xx
>>  CtraceClearText Off
>>  Trace7
>> }
>> 
>> TTLSConnectionAdvancedParms   cAdv-
>> {
>>  HandshakeTimeout 30
>>  CertificateLabel ATTLS
>>  SecondaryMap  Off
>>  TLSv1.2On
>>  ApplicationControlled  On
>> }
>> 
>> TTLSEnvironmentAction eAct1
>> {
>>  HandshakeRole Server
>>  EnvironmentUserInstance 0
>>  TTLSKeyringParmsRef keyR~ZOS112
>> }
>> 
>> 
>> ##---
>> ## IP Address for yyy Servers
>> ##---
>> IpAddrGroup   yyy-Server-IpAddr  {
>>  IpAddr
>>  {
>> Addr xx.xx.xx.xx
>>  }
>> }
>> 
>> ##---
>> ## Ports Remote
>> ##---
>> PortRange Port-Remote
>> {
>>  Port1024-65535
>> }
>> 
>> 

Re: Need some help with SSL error

[Keith Gooding]

Did you get any messages from AT-TLS  (prefix EZY) ?. Trace level 7 should 
cause error messages to appear on the job log in addition to the unix syslog. 
Maybe the rule is not being triggered. If you are able to increase the trace 
level to 31 you should be able to see what System SSL options were set by 
At-Tls (if the rule was triggered) . The debug messages are sent to syslogd. .

Keith Gooding 

> On 16 Nov 2020, at 14:24, Joe Monk  wrote:
> 
> Error 100B:
> 
> 100B Unexpected SSL handshake encountered.An SSL handshake header was
> encountered on a basic port or the client immediately entered an SSL
> handshake for a CONNTYPE option value other than SECURE or ANY. Verify that
> the client and port settings are compatible.
> A quick google found this:
> 
> https://www.ibm.com/support/pages/zos-communications-server-tls-needed-implement-tls-v12
> 
> Joe
> 
> 
> 
> 
>> On Mon, Nov 16, 2020 at 6:27 AM Edgington, Jerry <
>> jerry.edging...@westernsouthernlife.com> wrote:
>> 
>> I need some help, please.  We have an automated system, using TN3270
>> screen scraping.  Over the weekend, we IPL'ed, first time in April, 2020
>> and now, when this "automated" system/client tries to connect over TN3270,
>> we are getting this error message:
>> 
>> M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270
>> CONN 025C LU **N/A**  CONN DROP  ERR 100B 864
>> E 864 0090IP..PORT:
>> :::xx.xx.xx.xx..53084 EZBTTRCV
>> 
>> The AT/TLS policy has changed since August, 2020.  And we only have TLS
>> v1.2 turned on for only specific inbound IP addresses.  We are running z/OS
>> v2.1, at this point
>> 
>> Any suggestions, help or ideas, would be great.
>> 
>> Thanks,
>> Jerry Edgington
>> 
>> Here is the AT/TLS policy. I have masked the names for security reasons.
>> ##---
>> ## Rules for yyy servers using xx IP over port 923
>> ##---
>> TTLSRule  yyy-xx-SSL
>> {
>>  LocalAddrGroupRef x-Ip-Addr
>>  RemoteAddrGroupRef   yyy-Server-IpAddr
>>  LocalPortRange 923
>>  RemotePortRangeRef Port-Remote
>>  Direction Inbound
>>  Priority500
>>  TTLSGroupActionRef   gAct1
>>  TTLSEnvironmentActionRefeAct1
>>  TTLSConnectionActionRef cAct-x
>> }
>> 
>> TTLSConnectionAction  cAct-x
>> {
>>  HandshakeRole Server
>>  TTLSCipherParmsRef   cipher1~Default_Ciphers
>>  TTLSConnectionAdvancedParmsRef  cAdv-xx
>>  CtraceClearText Off
>>  Trace7
>> }
>> 
>> TTLSConnectionAdvancedParms   cAdv-
>> {
>>  HandshakeTimeout 30
>>  CertificateLabel ATTLS
>>  SecondaryMap  Off
>>  TLSv1.2On
>>  ApplicationControlled  On
>> }
>> 
>> TTLSEnvironmentAction eAct1
>> {
>>  HandshakeRole Server
>>  EnvironmentUserInstance 0
>>  TTLSKeyringParmsRef keyR~ZOS112
>> }
>> 
>> 
>> ##---
>> ## IP Address for yyy Servers
>> ##---
>> IpAddrGroup   yyy-Server-IpAddr  {
>>  IpAddr
>>  {
>> Addr xx.xx.xx.xx
>>  }
>> }
>> 
>> ##---
>> ## Ports Remote
>> ##---
>> PortRange Port-Remote
>> {
>>  Port1024-65535
>> }
>> 
>> --
>> 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: Improve OMVS cp performance?

[Seymour J Metz]

No, the 7030 was bit addressable. 

At the time of the S/360 announcement I thought that the decision to have a 
Model T "any byte size you want as long as it's 8" was a bad one, and I still 
think so. I also didn't like the 4 bit storage key and the 24 bit address. I 
thought that general registers might have been a good idea if there were 32, 
but that a maximum of base+index registers of 15 was too small.

What blindsided me was that IBM never supported the ASCII bit .


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



From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Monday, November 16, 2020 3:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Improve OMVS cp performance?

Mike Schwab wrote:
>You have to remember that S/360 was the first 8 bit computer.
>[]
>Sorry.  First computer to use 8 bits per character.

I see others have cited the IBM 7030 and Telefunken TR 4 as examples of
early computers that used (or at least were explicitly engineered to use)
8 bit character encoding. However, as far as I can tell both of those
machines were word addressable machines, and their word sizes were
different and much larger than their character sizes. Was there any
pre-System/360 example of a computer that stored characters in 8 bits
*and* offered 8 bit memory addressing? (Or 6 and 6, or 7 and 7?) For that
matter, are there any still extant digital computer processors that (only)
have word addressable memory and don't have 8 bit byte addressable memory?

History evidently judges that particular System/360 design decision as
wise or at least not unwise.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

--
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: Need some help with SSL error

[Edgington, Jerry]

Also, the TN3270 definition doesn't have CONNTYPE=SECURE specified, because we 
can only secure specific incoming IP addresses over port 923, not everything.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Edgington, Jerry
Sent: Monday, November 16, 2020 8:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need some help with SSL error

AT/TLS config:

TcpImage TCPIP /etc/pagent.conf FLUSH PURGE  
 
##LogLevel 31  ## Default logging level. 
##LogLevel 511 ## gives the most verbose logging 
LogLevel 32   ## Be verbose - Default is 31. 
 
ServicesConnection   
{
   Port 16311
   ImageName TCPIP   
   Security Basic
}
 
AutoMonitorParms 
{
   MonitorInterval 86400   ## 24 hours.  
   RetryLimitCount 5 
   RetryLimitPeriod86400   ## 24 hours.  
}

AutoMonitorApps 
{   
   AppName SYSLOGD  
   {
  ProcName SYSLOGD  
  JobName  SYSLOGD  
  StartParms   -c   
   }
}   
 
PAGENT_CONFIG_FILE=/etc/pagent.conf 
PAGENT_LOG_FILE=/var/log/pagent.log 
PAGENT_LOG_FILE_CONTROL=500,5   
TZ=EST5EDT  
   
 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Monday, November 16, 2020 8:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need some help with SSL error

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


Sorry ... my email client cut off the ATTLS parms and I didnt see them.

Joe

On Mon, Nov 16, 2020 at 7:06 AM Joe Monk  wrote:

> Error 100B:
>
> 100B Unexpected SSL handshake encountered.An SSL handshake header was 
> encountered on a basic port or the client immediately entered an SSL 
> handshake for a CONNTYPE option value other than SECURE or ANY. Verify 
> that the client and port settings are compatible.
> A quick google found this:
>
>
> https://www.ibm.com/support/pages/zos-communications-server-tls-needed
> -implement-tls-v12
>
> Joe
>
>
>
>
> On Mon, Nov 16, 2020 at 6:27 AM Edgington, Jerry < 
> jerry.edging...@westernsouthernlife.com> wrote:
>
>> I need some help, please.  We have an automated system, using TN3270 
>> screen scraping.  Over the weekend, we IPL'ed, first time in April,
>> 2020 and now, when this "automated" system/client tries to connect 
>> over TN3270, we are getting this error message:
>>
>> M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270
>> CONN 025C LU **N/A**  CONN DROP  ERR 100B 864
>> E 864 0090IP..PORT:
>> :::xx.xx.xx.xx..53084 EZBTTRCV
>>
>> The AT/TLS policy has changed since August, 2020.  And we only have 
>> TLS
>> v1.2 turned on for only specific inbound IP addresses.  We are 
>> running z/OS v2.1, at this point
>>
>> Any suggestions, help or ideas, would be great.
>>
>> Thanks,
>> Jerry Edgington
>>
>> Here is the AT/TLS policy. I have masked the names for security reasons.
>> ##---
>> ## Rules for yyy servers using xx IP over port 923
>> ##---
>> TTLSRule  yyy-xx-SSL
>> {
>>   LocalAddrGroupRef x-Ip-Addr
>>   RemoteAddrGroupRef   yyy-Server-IpAddr
>>   LocalPortRange 923
>>   RemotePortRangeRef Port-Remote
>>   Direction Inbound
>>   Priority500
>>   TTLSGroupActionRef   gAct1
>>   TTLSEnvironmentActionRef

Re: Need some help with SSL error

[Edgington, Jerry]

AT/TLS config:

TcpImage TCPIP /etc/pagent.conf FLUSH PURGE  
 
##LogLevel 31  ## Default logging level. 
##LogLevel 511 ## gives the most verbose logging 
LogLevel 32   ## Be verbose - Default is 31. 
 
ServicesConnection   
{
   Port 16311
   ImageName TCPIP   
   Security Basic
}
 
AutoMonitorParms 
{
   MonitorInterval 86400   ## 24 hours.  
   RetryLimitCount 5 
   RetryLimitPeriod86400   ## 24 hours.  
}

AutoMonitorApps 
{   
   AppName SYSLOGD  
   {
  ProcName SYSLOGD  
  JobName  SYSLOGD  
  StartParms   -c   
   }
}   
 
PAGENT_CONFIG_FILE=/etc/pagent.conf 
PAGENT_LOG_FILE=/var/log/pagent.log 
PAGENT_LOG_FILE_CONTROL=500,5   
TZ=EST5EDT  
   
 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Monday, November 16, 2020 8:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Need some help with SSL error

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


Sorry ... my email client cut off the ATTLS parms and I didnt see them.

Joe

On Mon, Nov 16, 2020 at 7:06 AM Joe Monk  wrote:

> Error 100B:
>
> 100B Unexpected SSL handshake encountered.An SSL handshake header was 
> encountered on a basic port or the client immediately entered an SSL 
> handshake for a CONNTYPE option value other than SECURE or ANY. Verify 
> that the client and port settings are compatible.
> A quick google found this:
>
>
> https://www.ibm.com/support/pages/zos-communications-server-tls-needed
> -implement-tls-v12
>
> Joe
>
>
>
>
> On Mon, Nov 16, 2020 at 6:27 AM Edgington, Jerry < 
> jerry.edging...@westernsouthernlife.com> wrote:
>
>> I need some help, please.  We have an automated system, using TN3270 
>> screen scraping.  Over the weekend, we IPL'ed, first time in April, 
>> 2020 and now, when this "automated" system/client tries to connect 
>> over TN3270, we are getting this error message:
>>
>> M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270
>> CONN 025C LU **N/A**  CONN DROP  ERR 100B 864
>> E 864 0090IP..PORT:
>> :::xx.xx.xx.xx..53084 EZBTTRCV
>>
>> The AT/TLS policy has changed since August, 2020.  And we only have 
>> TLS
>> v1.2 turned on for only specific inbound IP addresses.  We are 
>> running z/OS v2.1, at this point
>>
>> Any suggestions, help or ideas, would be great.
>>
>> Thanks,
>> Jerry Edgington
>>
>> Here is the AT/TLS policy. I have masked the names for security reasons.
>> ##---
>> ## Rules for yyy servers using xx IP over port 923
>> ##---
>> TTLSRule  yyy-xx-SSL
>> {
>>   LocalAddrGroupRef x-Ip-Addr
>>   RemoteAddrGroupRef   yyy-Server-IpAddr
>>   LocalPortRange 923
>>   RemotePortRangeRef Port-Remote
>>   Direction Inbound
>>   Priority500
>>   TTLSGroupActionRef   gAct1
>>   TTLSEnvironmentActionRefeAct1
>>   TTLSConnectionActionRef cAct-x
>> }
>>
>> TTLSConnectionAction  cAct-x
>> {
>>   HandshakeRole Server
>>   TTLSCipherParmsRef   cipher1~Default_Ciphers
>>   TTLSConnectionAdvancedParmsRef  cAdv-xx
>>   CtraceClearText Off
>>   Trace

Re: Need some help with SSL error

[Joe Monk]

Sorry ... my email client cut off the ATTLS parms and I didnt see them.

Joe

On Mon, Nov 16, 2020 at 7:06 AM Joe Monk  wrote:

> Error 100B:
>
> 100B Unexpected SSL handshake encountered.An SSL handshake header was
> encountered on a basic port or the client immediately entered an SSL
> handshake for a CONNTYPE option value other than SECURE or ANY. Verify that
> the client and port settings are compatible.
> A quick google found this:
>
>
> https://www.ibm.com/support/pages/zos-communications-server-tls-needed-implement-tls-v12
>
> Joe
>
>
>
>
> On Mon, Nov 16, 2020 at 6:27 AM Edgington, Jerry <
> jerry.edging...@westernsouthernlife.com> wrote:
>
>> I need some help, please.  We have an automated system, using TN3270
>> screen scraping.  Over the weekend, we IPL'ed, first time in April, 2020
>> and now, when this "automated" system/client tries to connect over TN3270,
>> we are getting this error message:
>>
>> M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270
>> CONN 025C LU **N/A**  CONN DROP  ERR 100B 864
>> E 864 0090IP..PORT:
>> :::xx.xx.xx.xx..53084 EZBTTRCV
>>
>> The AT/TLS policy has changed since August, 2020.  And we only have TLS
>> v1.2 turned on for only specific inbound IP addresses.  We are running z/OS
>> v2.1, at this point
>>
>> Any suggestions, help or ideas, would be great.
>>
>> Thanks,
>> Jerry Edgington
>>
>> Here is the AT/TLS policy. I have masked the names for security reasons.
>> ##---
>> ## Rules for yyy servers using xx IP over port 923
>> ##---
>> TTLSRule  yyy-xx-SSL
>> {
>>   LocalAddrGroupRef x-Ip-Addr
>>   RemoteAddrGroupRef   yyy-Server-IpAddr
>>   LocalPortRange 923
>>   RemotePortRangeRef Port-Remote
>>   Direction Inbound
>>   Priority500
>>   TTLSGroupActionRef   gAct1
>>   TTLSEnvironmentActionRefeAct1
>>   TTLSConnectionActionRef cAct-x
>> }
>>
>> TTLSConnectionAction  cAct-x
>> {
>>   HandshakeRole Server
>>   TTLSCipherParmsRef   cipher1~Default_Ciphers
>>   TTLSConnectionAdvancedParmsRef  cAdv-xx
>>   CtraceClearText Off
>>   Trace7
>> }
>>
>> TTLSConnectionAdvancedParms   cAdv-
>> {
>>   HandshakeTimeout 30
>>   CertificateLabel ATTLS
>>   SecondaryMap  Off
>>   TLSv1.2On
>>   ApplicationControlled  On
>> }
>>
>> TTLSEnvironmentAction eAct1
>> {
>>   HandshakeRole Server
>>   EnvironmentUserInstance 0
>>   TTLSKeyringParmsRef keyR~ZOS112
>> }
>>
>>
>> ##---
>> ## IP Address for yyy Servers
>> ##---
>> IpAddrGroup   yyy-Server-IpAddr  {
>>   IpAddr
>>   {
>>  Addr xx.xx.xx.xx
>>   }
>> }
>>
>> ##---
>> ## Ports Remote
>> ##---
>> PortRange Port-Remote
>> {
>>   Port1024-65535
>> }
>>
>> --
>> 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: Need some help with SSL error

[Joe Monk]

Error 100B:

100B Unexpected SSL handshake encountered.An SSL handshake header was
encountered on a basic port or the client immediately entered an SSL
handshake for a CONNTYPE option value other than SECURE or ANY. Verify that
the client and port settings are compatible.
A quick google found this:

https://www.ibm.com/support/pages/zos-communications-server-tls-needed-implement-tls-v12

Joe




On Mon, Nov 16, 2020 at 6:27 AM Edgington, Jerry <
jerry.edging...@westernsouthernlife.com> wrote:

> I need some help, please.  We have an automated system, using TN3270
> screen scraping.  Over the weekend, we IPL'ed, first time in April, 2020
> and now, when this "automated" system/client tries to connect over TN3270,
> we are getting this error message:
>
> M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270
> CONN 025C LU **N/A**  CONN DROP  ERR 100B 864
> E 864 0090IP..PORT:
> :::xx.xx.xx.xx..53084 EZBTTRCV
>
> The AT/TLS policy has changed since August, 2020.  And we only have TLS
> v1.2 turned on for only specific inbound IP addresses.  We are running z/OS
> v2.1, at this point
>
> Any suggestions, help or ideas, would be great.
>
> Thanks,
> Jerry Edgington
>
> Here is the AT/TLS policy. I have masked the names for security reasons.
> ##---
> ## Rules for yyy servers using xx IP over port 923
> ##---
> TTLSRule  yyy-xx-SSL
> {
>   LocalAddrGroupRef x-Ip-Addr
>   RemoteAddrGroupRef   yyy-Server-IpAddr
>   LocalPortRange 923
>   RemotePortRangeRef Port-Remote
>   Direction Inbound
>   Priority500
>   TTLSGroupActionRef   gAct1
>   TTLSEnvironmentActionRefeAct1
>   TTLSConnectionActionRef cAct-x
> }
>
> TTLSConnectionAction  cAct-x
> {
>   HandshakeRole Server
>   TTLSCipherParmsRef   cipher1~Default_Ciphers
>   TTLSConnectionAdvancedParmsRef  cAdv-xx
>   CtraceClearText Off
>   Trace7
> }
>
> TTLSConnectionAdvancedParms   cAdv-
> {
>   HandshakeTimeout 30
>   CertificateLabel ATTLS
>   SecondaryMap  Off
>   TLSv1.2On
>   ApplicationControlled  On
> }
>
> TTLSEnvironmentAction eAct1
> {
>   HandshakeRole Server
>   EnvironmentUserInstance 0
>   TTLSKeyringParmsRef keyR~ZOS112
> }
>
>
> ##---
> ## IP Address for yyy Servers
> ##---
> IpAddrGroup   yyy-Server-IpAddr  {
>   IpAddr
>   {
>  Addr xx.xx.xx.xx
>   }
> }
>
> ##---
> ## Ports Remote
> ##---
> PortRange Port-Remote
> {
>   Port1024-65535
> }
>
> --
> 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

Need some help with SSL error

[Edgington, Jerry]

I need some help, please.  We have an automated system, using TN3270 screen 
scraping.  Over the weekend, we IPL'ed, first time in April, 2020 and now, when 
this "automated" system/client tries to connect over TN3270, we are getting 
this error message:

M 410  20320 14:22:03.02 STC09624 0090  EZZ6034I TN3270 CONN 
025C LU **N/A**  CONN DROP  ERR 100B 864
E 864 0090IP..PORT: 
:::xx.xx.xx.xx..53084 EZBTTRCV

The AT/TLS policy has changed since August, 2020.  And we only have TLS v1.2 
turned on for only specific inbound IP addresses.  We are running z/OS v2.1, at 
this point

Any suggestions, help or ideas, would be great.

Thanks,
Jerry Edgington

Here is the AT/TLS policy. I have masked the names for security reasons.
##---
## Rules for yyy servers using xx IP over port 923
##---
TTLSRule  yyy-xx-SSL
{
  LocalAddrGroupRef x-Ip-Addr
  RemoteAddrGroupRef   yyy-Server-IpAddr
  LocalPortRange 923
  RemotePortRangeRef Port-Remote
  Direction Inbound
  Priority500
  TTLSGroupActionRef   gAct1
  TTLSEnvironmentActionRefeAct1
  TTLSConnectionActionRef cAct-x
}

TTLSConnectionAction  cAct-x
{
  HandshakeRole Server
  TTLSCipherParmsRef   cipher1~Default_Ciphers
  TTLSConnectionAdvancedParmsRef  cAdv-xx
  CtraceClearText Off
  Trace7
}

TTLSConnectionAdvancedParms   cAdv-
{
  HandshakeTimeout 30
  CertificateLabel ATTLS
  SecondaryMap  Off
  TLSv1.2On
  ApplicationControlled  On
}

TTLSEnvironmentAction eAct1
{
  HandshakeRole Server
  EnvironmentUserInstance 0
  TTLSKeyringParmsRef keyR~ZOS112
}


##---
## IP Address for yyy Servers
##---
IpAddrGroup   yyy-Server-IpAddr  {
  IpAddr
  {
 Addr xx.xx.xx.xx
  }
}

##---
## Ports Remote
##---
PortRange Port-Remote
{
  Port1024-65535
}

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

Re: Improve OMVS cp performance?

[Timothy Sipples]

Mike Schwab wrote:
>You have to remember that S/360 was the first 8 bit computer.
>[]
>Sorry.  First computer to use 8 bits per character.

I see others have cited the IBM 7030 and Telefunken TR 4 as examples of 
early computers that used (or at least were explicitly engineered to use) 
8 bit character encoding. However, as far as I can tell both of those 
machines were word addressable machines, and their word sizes were 
different and much larger than their character sizes. Was there any 
pre-System/360 example of a computer that stored characters in 8 bits 
*and* offered 8 bit memory addressing? (Or 6 and 6, or 7 and 7?) For that 
matter, are there any still extant digital computer processors that (only) 
have word addressable memory and don't have 8 bit byte addressable memory?

History evidently judges that particular System/360 design decision as 
wise or at least not unwise.

- - - - - - - - - -
Timothy Sipples
I.T. Architect Executive
Digital Asset & Other Industry Solutions
IBM Z & LinuxONE
- - - - - - - - - -
E-Mail: sipp...@sg.ibm.com

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