Re: 3270 terminals: CUT vs. DFT

[Timothy Sipples]

Alex, have you considered getting a used terminal controller for your IBM 
3290? It looks like an IBM 3174 would work.

According to IBM Publication No. GG24-3061 (Revision -05 is the latest I 
can find), the IBM 3290 requires a "Downstream Load (DSL) Diskette." This 
feature in turn requires any of the following feature codes: 1046, 1048, 
or 1056 (i.e. a second diskette drive or hard disk). Sadly, none of these 
three feature codes are available on the smallest form factor 3174 models 
81R, 82R, 90R, 91R, and 92R. Thus the most likely "best fit" IBM 3174 
would be one of the 5xR or 6xR "medium size" models, preferably 6xR since 
that's the newer one. Some of these models had Ethernet and/or serial 
("asynchronous") ports.

I found some online evidence that a hobbyist managed to get an IBM 3290 
with IBM 3174 connected to and functioning with a Linux-based PC.

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

IBM's Java on z/OS Survey Request

[Timothy Sipples]

IBM is soliciting some special feedback for Java on z/OS. The survey is 
available here through May 29, 2020:

https://ibm.biz/zOSJavaSurvey

Thanks.

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

Re: TMSINIT

[Russell Witt]

Not exactly. The SECWTO does control if the WTOR asking for the userid and
password of the user running TMSINIT as a started task is issued or not.
However, you can change the option at any time. The "trick" is that if you
change the option; it does not take effect until AFTER you have successfully
executed TMSINIT to reset the option. So, you cannot just change the option
and then run TMSINIT without the WTOR being issued. It will be the next time
after before it takes effect.

Now, one simple method for bypassing the WTOR is to not run TMSINIT as a
started task. If it is run as a batch job (or even from TSO if you allocate
the necessary files) you will not be prompted for the userid/password of the
user running TMSINIT. And it is NOT the user-id of TMSINIT itself; it is
simply the user-id of the person that entered the "S TMSINIT" operator
command. In other words, WHO is running TMSINIT as a started task. 
If the SECWTO option is set to NO, we won't ask and will simply allow anyone
to run TMSINIT at any time (not exactly a secure way of running, but that is
an option).

Russell Witt
CA 1 Architect
Broadcom

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Nai, Dean
Sent: Tuesday, May 12, 2020 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TMSINIT

If I remember correctly if SECTWO is set to yes at IPL then it remembers it
until the next IPL and if you change it to no it won't work until the next
IPL.

Thanks:)



From: IBM Mainframe Discussion List  on behalf of
Carmen Vitullo 
Sent: Tuesday, May 12, 2020 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TMSINIT

EXTERNAL:  Do not open attachments or click on links unless you recognize
and trust the sender.

IIRC it's the password used when you installed CA-1, one of the usermods,
some sites use the default.
it should be in a usermod or sampjcl member


Carmen Vitullo

- Original Message -

From: "Dean Nai" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, May 12, 2020 12:30:23 PM
Subject: TMSINIT

I know this isn't a Z question but people on here have knowledge about most
things.


I'm trying to run a CA-1 TMSINIT outside of an IPL and I'm getting this
message. Nobody here knows what to reply. Any thoughts.


IEFTMS32 - ENTER USERID AUTHORIZED TO RUN TMSINIT

--
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: 3270 terminals: CUT vs. DFT

[Seymour J Metz]

Ignoring the fact that there is a reference card, that's the sort of thing for 
which I would throw together a Q program rather than doing it by hand. I 
don't like deciphering data streams, and I do like programming.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom 
Brennan [t...@tombrennansoftware.com]
Sent: Tuesday, May 12, 2020 10:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 3270 terminals: CUT vs. DFT

On 5/12/2020 4:29 PM, Phil Smith III wrote:
> ... 3270 data streams were fun because they were so complex.

Ha!  Reminds me of when I was a trainee installing InfoMan V1 (I think)
which was supplied with various 3270 screens in binary form, and no
utility to edit them.  To change a screen I had to learn the basic 3270
codes including SBA (Set Buffer Address) followed by 2 byte addresses
that made little sense.  So I made a 24x80 paper chart for myself with
every address.

One of the experienced sysprogs saw me working on that chart late one
evening and complained, "Is this the kind of busy-work they are making
the trainee's do??"  I didn't know what to say so I kept quiet.  To me
it was fun.

--
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: 3270 terminals: CUT vs. DFT

[Tom Brennan]

On 5/12/2020 4:29 PM, Phil Smith III wrote:
... 3270 data streams were fun because they were so complex. 


Ha!  Reminds me of when I was a trainee installing InfoMan V1 (I think) 
which was supplied with various 3270 screens in binary form, and no 
utility to edit them.  To change a screen I had to learn the basic 3270 
codes including SBA (Set Buffer Address) followed by 2 byte addresses 
that made little sense.  So I made a 24x80 paper chart for myself with 
every address.


One of the experienced sysprogs saw me working on that chart late one 
evening and complained, "Is this the kind of busy-work they are making 
the trainee's do??"  I didn't know what to say so I kept quiet.  To me 
it was fun.


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

Re: Developers say Google's Go is 'most sought after' programming language of 2020

[Seymour J Metz]

No oorexx, or even Regina?

Although I was impressed to see Erlang there; I hadn't expected that.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mike Schwab [mike.a.sch...@gmail.com]
Sent: Tuesday, May 12, 2020 9:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Developers say Google's Go is 'most sought after' programming 
language of 2020

https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/elizabeth-k-joseph1/2020/05/12/linuxone-open-source-report-april-2020

On Tue, May 12, 2020 at 7:33 PM Jack J. Woehr  wrote:
>
> On 5/12/20 9:28 AM, Seymour J Metz wrote:
> > I also want them in Linux for Z, but that may already be here.
>
> You do know that you can get a free LPAR for 90 days and explore what's
> there and what's not yourself, right?
>
> https://developer.ibm.com/components/ibm-linuxone/gettingstarted/
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> http://secure-web.cisco.com/1BjXeamASb4arcahwb3X_bVQ0vg1zkKqkXE2Oawiu7QyDd6iR_0C2aB4tWakA75ldQOc_-3Ael5XrPYgifkeBQdvLE156ILmfzx3x0a7nn0WS2R6ikyg9WpbNA52LzSpNh7kf893lNSmOoa31e_I__klhz6vFhUmPJ0McdRbYlOEdhrXgiKxpIlHtegcB6jQt6Y7dgHu72u7SzJhAI8swIWpFD6V4G3ja-XrejXb_OF8YoPRDYavvDYt1CMyn0PwApJdFMGwPWm6xbezBcGx87BN0DRKzNGPYuZLY3FXgRk22jOWEkKwVYo6NTnDUgcDEyBqikrhhhto-NuBWKbqHez4HUQGrasMTslvTyNW4bsTiknTTE1WN3nuGTBeg4WcnNcZTpw2QmE-3e9VfKs8OcRzekVhMn4X3S_Bu0yke2swLArizUOYDSL74MOuPo2XK/http%3A%2F%2Fwww.well.com%2F%7Ejax
>  # thinking, a way of skeptically interrogating the universe
> http://secure-web.cisco.com/1Q-yRLyiAm0nZ_A3qvYIii8As2kFRFiHYe5ZnN2lSVirZFSOCIZ0Qad3Q-c1PayY6ESNk1QEhlOggOkTO16wK3-dlwX_a28oAa1uZcSROAyh_5xXDh1VoriGNW9YbaUQY1nWobHGKw1kdnK0Np5Coo_L5PTCtrhU1r_Tl9PDg3UQKx8-TseREo3-nxn4jo92b5b_D_nQc6e4XXwPE0KOztmkfGw3CfEpfPyHSuEHeJN3Z9ge56FVl3nU53HvqEvznOB9VIx-GjCHdw3lImkrmlaDYq-Mss5-3YRtBRmt8yNT6y451lq88omM6EznwpYrjmlApFTKjgj3RTH7aStbiawyVEjbaa0hwfQXPkdAA6jl9CMoc6WUfsnKKSGdVLnTFHizlDP0iCOjlJNsfXz907uPOqwrZeQJmvJfF6SwRMjFuhjbS0C0G7PORWsohfvCY/http%3A%2F%2Fwww.softwoehr.com
>  # with a fine understanding of human fallibility. - Carl Sagan
>
> --
> 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: Developers say Google's Go is 'most sought after' programming language of 2020

[Mike Schwab]

https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/elizabeth-k-joseph1/2020/05/12/linuxone-open-source-report-april-2020

On Tue, May 12, 2020 at 7:33 PM Jack J. Woehr  wrote:
>
> On 5/12/20 9:28 AM, Seymour J Metz wrote:
> > I also want them in Linux for Z, but that may already be here.
>
> You do know that you can get a free LPAR for 90 days and explore what's
> there and what's not yourself, right?
>
> https://developer.ibm.com/components/ibm-linuxone/gettingstarted/
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the universe
> www.softwoehr.com # with a fine understanding of human fallibility. - Carl 
> Sagan
>
> --
> 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

Re: An older device query - still using??

[Seymour J Metz]

That would be the Direct Control feature. Was there any other user besides the 
1419 and 65MP?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Tuesday, May 12, 2020 6:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

I think you guys are confusing the 3890's and the 1419. The 1419
required a special interrupt line to the processor. This would dispatch
a system subtask designed to handle just the checks 'disposition', in
other words, which pocket the check would be routed to. The, it would
create an output buffer to be read by the check handling software which
ran in another region.

The 3890's, on the other hand, were really "stand alone" devices. Many
actually had left-over 360's as the front end controller. The 360
handled the interrupts using special software "sky code" (name is hazy?)
which handled the check disposition decisions. Then, on a less time
critical manner, the 360 send the output data up to the "real" mainframe
were it was processed by the check handling software.

The special interrupt line (that supported the 1419) was dropped a
*LONG* time ago from processors.

Tony Thigpen

Farley, Peter x23353 wrote on 5/12/20 5:02 PM:
> I worked at the NY Federal Reserve Bank in the early 70's when they were 
> trying to use 3890 check readers for clearing "country bank" checks (i.e., 
> any bank in the Fed's district except the 7 big ones in NYC who were handled 
> by ACH, the "Automated Clearing House").  MVT, 360/65 with 512K storage and 
> very early CICS - they never did get it working, the timing had to be so 
> quick that after the check was read they had to direct the machine to put it 
> into the right output pocket (EXCP-level I/O was required to do this).  Never 
> did work.
>
> The 3890 was a huge machine that looked like a card sorter on steroids.
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Paul Gilmartin
> Sent: Tuesday, May 12, 2020 4:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: An older device query - still using??
>
> On Tue, 12 May 2020 15:26:12 -0500, Matthew Stitt wrote:
>
>> Has anyone checked with the banking customers?  I recall there was software 
>> for check reader hardware.  The 3890 seems to ring a bell.  Also a quick 
>> Internet search confirms my suspicions that the 3895 was a check printer and 
>> the 3890 was a check reader.
>>
>> I still write checks  
>>
> Ed Gould, answering my question a while ago, said the timing requirements of 
> such a device were so strict that it would have crashed during a leap second. 
>  When did MVS introduce leap second support?  But perhaps the designers 
> didn't worry about an exposure every couple years.
>
>> On Tue, 12 May 2020 14:40:37 -0500, Marna WALLE wrote:
>>
>>> Hello All,
>>> We had an internal small discussion wondering if there were any customers 
>>> that still used these devices (the youngest of which went end-of-service in 
>>> 2014, from what I can find).  I wanted to extend this conversation outside 
>>> of IBM, to those that might have firsthand current knowledge.
>>>
>>> Here's the devices I'm wondering about:
>>>
>>> 1287/1288 - IBM Optical reader and page reader respectively
>>> 3540 - IBM Disk device
>>> 3886 - IBM Optical Character reader
>>> 3890 - IBM Magnetic Ink Reader
>>> 3895 - IBM Printer device
>
> --
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: 3270 terminals: CUT vs. DFT

[Seymour J Metz]

I like the 3270 data stream, but if I could make one change in industry usage 
it would be to replace most HTTP/HTML applications with X Window System (X11); 
SUN's old dream of X terminals, except that I see a thin client as being an 
application on a full fore PC, not a dedicated application on a minimal PC.

Long ago in a galaxy far away, I had to do software that provided a common 
interface to a bunch of dissimilar terminals. While I sort of used the 3270 as 
a starting point, I did away with things that I regarded as warts, e.g., all 
buffer addresses were 16 bits. Using an unmodified 3270 datastream would not 
have been satisfactory. And, yes, I did support various 3270 devices.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Tuesday, May 12, 2020 7:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 3270 terminals: CUT vs. DFT

Martin Packer wrote:

>It's such a nice efficient data stream that one might like to use it from

>other platforms.



"Efficient" how? Bandwidth? That's cheap now. 3270 data streams were fun 
because they were so complex. But expensive to program and use. And the fact 
that attribute bytes occupy space on the screen is really irritating when 
trying to design screens.



I honestly can't imagine anyone wanting to reuse it-and the fact that nobody 
ever has might be seen as supporting that position.



But each to his own!


--
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: 3270 terminals: CUT vs. DFT

[Phil Smith III]

Martin Packer wrote:

>It's such a nice efficient data stream that one might like to use it from

>other platforms.

 

"Efficient" how? Bandwidth? That's cheap now. 3270 data streams were fun 
because they were so complex. But expensive to program and use. And the fact 
that attribute bytes occupy space on the screen is really irritating when 
trying to design screens.

 

I honestly can't imagine anyone wanting to reuse it-and the fact that nobody 
ever has might be seen as supporting that position.

 

But each to his own!


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

Re: An older device query - still using??

[Glenn Miller]

The 3890 Document Processor (Check Reader/Sorter) was a buffered device that 
removed the issues of "timing" that existed with the 1419 Magnetic Character.  
The "sky code" was actually the Stacker Control Instructions  ( or SCI ) which 
were downloaded from the MVS or DOS/VS (E) host into the 3890's "brains". The 
SCI program looked "kinda like" ( but not really ) a S/360 Assembler program. 
The SCI program determined which "pocket" on the 3890 each document would be 
placed in. The SCI program was actually compiled/assembled on the MVS or 
DOS/VS(E) host using the native Assembler program for that Operating System.  
However, each SCI program "instruction" was actually an Assembler macro instead 
of a "native assembler program" that the 37x5 machines had on MVS and 
DOS/VS(E). We were told in 3890 SCI programming class that the "brains" of the 
1st generation of 3890's were S/360 Model 25 machines. I don't know if that was 
true.

HTH
Glenn

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

Re: An older device query - still using??

[Farley, Peter x23353]

Tony,

You are absolutely correct, I did confuse the 3890 with the 1419.  The NY Fed 
tried to use 1419 devices, not 3890's.

Mea culpa.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Thigpen
Sent: Tuesday, May 12, 2020 6:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

I think you guys are confusing the 3890's and the 1419. The 1419 required a 
special interrupt line to the processor. This would dispatch a system subtask 
designed to handle just the checks 'disposition', in other words, which pocket 
the check would be routed to. The, it would create an output buffer to be read 
by the check handling software which ran in another region.

The 3890's, on the other hand, were really "stand alone" devices. Many actually 
had left-over 360's as the front end controller. The 360 handled the interrupts 
using special software "sky code" (name is hazy?) which handled the check 
disposition decisions. Then, on a less time critical manner, the 360 send the 
output data up to the "real" mainframe were it was processed by the check 
handling software.

The special interrupt line (that supported the 1419) was dropped a
*LONG* time ago from processors.

Tony Thigpen

Farley, Peter x23353 wrote on 5/12/20 5:02 PM:
> I worked at the NY Federal Reserve Bank in the early 70's when they were 
> trying to use 3890 check readers for clearing "country bank" checks (i.e., 
> any bank in the Fed's district except the 7 big ones in NYC who were handled 
> by ACH, the "Automated Clearing House").  MVT, 360/65 with 512K storage and 
> very early CICS - they never did get it working, the timing had to be so 
> quick that after the check was read they had to direct the machine to put it 
> into the right output pocket (EXCP-level I/O was required to do this).  Never 
> did work.
> 
> The 3890 was a huge machine that looked like a card sorter on steroids.
> 
> Peter
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Paul Gilmartin
> Sent: Tuesday, May 12, 2020 4:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: An older device query - still using??
> 
> On Tue, 12 May 2020 15:26:12 -0500, Matthew Stitt wrote:
> 
>> Has anyone checked with the banking customers?  I recall there was software 
>> for check reader hardware.  The 3890 seems to ring a bell.  Also a quick 
>> Internet search confirms my suspicions that the 3895 was a check printer and 
>> the 3890 was a check reader.
>>
>> I still write checks  
>>
> Ed Gould, answering my question a while ago, said the timing requirements of 
> such a device were so strict that it would have crashed during a leap second. 
>  When did MVS introduce leap second support?  But perhaps the designers 
> didn't worry about an exposure every couple years.
> 
>> On Tue, 12 May 2020 14:40:37 -0500, Marna WALLE wrote:
>>
>>> Hello All,
>>> We had an internal small discussion wondering if there were any customers 
>>> that still used these devices (the youngest of which went end-of-service in 
>>> 2014, from what I can find).  I wanted to extend this conversation outside 
>>> of IBM, to those that might have firsthand current knowledge.
>>>
>>> Here's the devices I'm wondering about:
>>>
>>> 1287/1288 - IBM Optical reader and page reader respectively
>>> 3540 - IBM Disk device
>>> 3886 - IBM Optical Character reader
>>> 3890 - IBM Magnetic Ink Reader
>>> 3895 - IBM Printer device
> 
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Software bug wipes out traders

[Kirk Wolf]

https://www.bloomberg.com/news/articles/2020-05-08/oil-crash-busted-a-broker-s-computers-and-inflicted-huge-losses

FWIW: I see  no mention of "outdated 40 year old mainframes" or COBOL "-)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

Re: An older device query - still using??

[Tony Thigpen]

I think you guys are confusing the 3890's and the 1419. The 1419 
required a special interrupt line to the processor. This would dispatch 
a system subtask designed to handle just the checks 'disposition', in 
other words, which pocket the check would be routed to. The, it would 
create an output buffer to be read by the check handling software which 
ran in another region.


The 3890's, on the other hand, were really "stand alone" devices. Many 
actually had left-over 360's as the front end controller. The 360 
handled the interrupts using special software "sky code" (name is hazy?) 
which handled the check disposition decisions. Then, on a less time 
critical manner, the 360 send the output data up to the "real" mainframe 
were it was processed by the check handling software.


The special interrupt line (that supported the 1419) was dropped a 
*LONG* time ago from processors.


Tony Thigpen

Farley, Peter x23353 wrote on 5/12/20 5:02 PM:

I worked at the NY Federal Reserve Bank in the early 70's when they were trying to use 3890 check 
readers for clearing "country bank" checks (i.e., any bank in the Fed's district except 
the 7 big ones in NYC who were handled by ACH, the "Automated Clearing House").  MVT, 
360/65 with 512K storage and very early CICS - they never did get it working, the timing had to be 
so quick that after the check was read they had to direct the machine to put it into the right 
output pocket (EXCP-level I/O was required to do this).  Never did work.

The 3890 was a huge machine that looked like a card sorter on steroids.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, May 12, 2020 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

On Tue, 12 May 2020 15:26:12 -0500, Matthew Stitt wrote:


Has anyone checked with the banking customers?  I recall there was software for 
check reader hardware.  The 3890 seems to ring a bell.  Also a quick Internet 
search confirms my suspicions that the 3895 was a check printer and the 3890 
was a check reader.

I still write checks  


Ed Gould, answering my question a while ago, said the timing requirements of 
such a device were so strict that it would have crashed during a leap second.  
When did MVS introduce leap second support?  But perhaps the designers didn't 
worry about an exposure every couple years.


On Tue, 12 May 2020 14:40:37 -0500, Marna WALLE wrote:


Hello All,
We had an internal small discussion wondering if there were any customers that 
still used these devices (the youngest of which went end-of-service in 2014, 
from what I can find).  I wanted to extend this conversation outside of IBM, to 
those that might have firsthand current knowledge.

Here's the devices I'm wondering about:

1287/1288 - IBM Optical reader and page reader respectively
3540 - IBM Disk device
3886 - IBM Optical Character reader
3890 - IBM Magnetic Ink Reader
3895 - IBM Printer device


--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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



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

Re: An older device query - still using??

[Farley, Peter x23353]

I worked at the NY Federal Reserve Bank in the early 70's when they were trying 
to use 3890 check readers for clearing "country bank" checks (i.e., any bank in 
the Fed's district except the 7 big ones in NYC who were handled by ACH, the 
"Automated Clearing House").  MVT, 360/65 with 512K storage and very early CICS 
- they never did get it working, the timing had to be so quick that after the 
check was read they had to direct the machine to put it into the right output 
pocket (EXCP-level I/O was required to do this).  Never did work.

The 3890 was a huge machine that looked like a card sorter on steroids.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Tuesday, May 12, 2020 4:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: An older device query - still using??

On Tue, 12 May 2020 15:26:12 -0500, Matthew Stitt wrote:

>Has anyone checked with the banking customers?  I recall there was software 
>for check reader hardware.  The 3890 seems to ring a bell.  Also a quick 
>Internet search confirms my suspicions that the 3895 was a check printer and 
>the 3890 was a check reader.
>
>I still write checks  
> 
Ed Gould, answering my question a while ago, said the timing requirements of 
such a device were so strict that it would have crashed during a leap second.  
When did MVS introduce leap second support?  But perhaps the designers didn't 
worry about an exposure every couple years.

>On Tue, 12 May 2020 14:40:37 -0500, Marna WALLE wrote:
>
>>Hello All,
>>We had an internal small discussion wondering if there were any customers 
>>that still used these devices (the youngest of which went end-of-service in 
>>2014, from what I can find).  I wanted to extend this conversation outside of 
>>IBM, to those that might have firsthand current knowledge.
>>
>>Here's the devices I'm wondering about:
>>
>>1287/1288 - IBM Optical reader and page reader respectively
>>3540 - IBM Disk device
>>3886 - IBM Optical Character reader
>>3890 - IBM Magnetic Ink Reader
>>3895 - IBM Printer device

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: An older device query - still using??

[Paul Gilmartin]

On Tue, 12 May 2020 15:26:12 -0500, Matthew Stitt wrote:

>Has anyone checked with the banking customers?  I recall there was software 
>for check reader hardware.  The 3890 seems to ring a bell.  Also a quick 
>Internet search confirms my suspicions that the 3895 was a check printer and 
>the 3890 was a check reader.
>
>I still write checks  
> 
Ed Gould, answering my question a while ago, said the timing
requirements of such a device were so strict that it would have
crashed during a leap second.  When did MVS introduce leap
second support?  But perhaps the designers didn't worry about
an exposure every couple years.

>On Tue, 12 May 2020 14:40:37 -0500, Marna WALLE wrote:
>
>>Hello All,
>>We had an internal small discussion wondering if there were any customers 
>>that still used these devices (the youngest of which went end-of-service in 
>>2014, from what I can find).  I wanted to extend this conversation outside of 
>>IBM, to those that might have firsthand current knowledge.
>>
>>Here's the devices I'm wondering about:
>>
>>1287/1288 - IBM Optical reader and page reader respectively
>>3540 - IBM Disk device
>>3886 - IBM Optical Character reader
>>3890 - IBM Magnetic Ink Reader
>>3895 - IBM Printer device

-- gil

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

Re: An older device query - still using??

[Matthew Stitt]

Has anyone checked with the banking customers?  I recall there was software for 
check reader hardware.  The 3890 seems to ring a bell.  Also a quick Internet 
search confirms my suspicions that the 3895 was a check printer and the 3890 
was a check reader.

I still write checks  

Matthew

On Tue, 12 May 2020 14:40:37 -0500, Marna WALLE  wrote:

>Hello All,
>We had an internal small discussion wondering if there were any customers that 
>still used these devices (the youngest of which went end-of-service in 2014, 
>from what I can find).  I wanted to extend this conversation outside of IBM, 
>to those that might have firsthand current knowledge.
>
>Here's the devices I'm wondering about:
>
>1287/1288 - IBM Optical reader and page reader respectively
>3540 - IBM Disk device
>3886 - IBM Optical Character reader
>3890 - IBM Magnetic Ink Reader
>3895 - IBM Printer device
>
>If you or someone you know *currently* has one of the above devices in use, 
>would you mind contacting me?  I'm not interested in the past, when I know 
>these were once-popular devices. For instance, all LinkedIn hits I read were 
>all "prior experience" type of references. 
>
>I'm interested in current 2020 usage of them.  I appreciate learning about 
>this.
>-Marna WALLE
>z/OS Installation, IBM Poughkeepsie
>mwa...@us.ibm.com

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

An older device query - still using??

[Marna WALLE]

Hello All,
We had an internal small discussion wondering if there were any customers that 
still used these devices (the youngest of which went end-of-service in 2014, 
from what I can find).  I wanted to extend this conversation outside of IBM, to 
those that might have firsthand current knowledge.

Here's the devices I'm wondering about:

1287/1288 - IBM Optical reader and page reader respectively
3540 - IBM Disk device
3886 - IBM Optical Character reader
3890 - IBM Magnetic Ink Reader
3895 - IBM Printer device

If you or someone you know *currently* has one of the above devices in use, 
would you mind contacting me?  I'm not interested in the past, when I know 
these were once-popular devices. For instance, all LinkedIn hits I read were 
all "prior experience" type of references. 

I'm interested in current 2020 usage of them.  I appreciate learning about this.
-Marna WALLE
z/OS Installation, IBM Poughkeepsie
mwa...@us.ibm.com

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

Re: Developers say Google's Go is 'most sought after' programming language of 2020

[Jack J. Woehr]

On 5/12/20 9:28 AM, Seymour J Metz wrote:

I also want them in Linux for Z, but that may already be here.


You do know that you can get a free LPAR for 90 days and explore what's 
there and what's not yourself, right?


https://developer.ibm.com/components/ibm-linuxone/gettingstarted/

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: IDCAMS not freeing file

[Tim Hare]

Questions:

1. Is this the same VSAM file shared between the two partitions?
2. Is the VSAM file referenced in JCL anywhere, or just in the commands in 
IDCAMS?

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

Re: Go> Colossus> Devs

[scott Ford]

Sounds good Ken I will chec it out, thx.

Scott

On Tue, May 12, 2020 at 2:44 PM Ken Smith  wrote:

> For SF fans or Philosophy majors try the FX/Hulu TV series "Devs
> ".  From the NYTimes:
>
> *"In “Devs,” ... a messianic tech founder devises a supercomputer that can
> simulate the past and predict the future, based on principles of physical
> determinism."*
>
> Artfully filmed, it imagines a computer with the astounding capacity to
> "know" every moment in time. Extrapolating backward or forward, it can show
> these events, for example, Jesus on the cross.  This presumes, however,
> that all events are predetermined, that is, there is no free will -
> everything that has happened or will happen is immutable.  Or is it?
>
> Unique to the "computer run amok" genre this computer is not out of control
> but in fact does exactly what developers have programmed it to do.
>
> Excellent.
>
> Ken
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Go> Colossus> Devs

[Ken Smith]

For SF fans or Philosophy majors try the FX/Hulu TV series "Devs
".  From the NYTimes:

*"In “Devs,” ... a messianic tech founder devises a supercomputer that can
simulate the past and predict the future, based on principles of physical
determinism."*

Artfully filmed, it imagines a computer with the astounding capacity to
"know" every moment in time. Extrapolating backward or forward, it can show
these events, for example, Jesus on the cross.  This presumes, however,
that all events are predetermined, that is, there is no free will -
everything that has happened or will happen is immutable.  Or is it?

Unique to the "computer run amok" genre this computer is not out of control
but in fact does exactly what developers have programmed it to do.

Excellent.

Ken

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

Re: TMSINIT

[Lizette Koehler]

As has been pointed out

The message is produced when SECWTO is set to YES



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Nai, Dean
Sent: Tuesday, May 12, 2020 10:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TMSINIT

I know this isn't a Z question but people on here have knowledge about most
things.


I'm trying to run a CA-1 TMSINIT outside of an IPL and I'm getting this
message. Nobody here knows what to reply. Any thoughts.


IEFTMS32 - ENTER USERID AUTHORIZED TO RUN TMSINIT

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

[Nai, Dean]

If I remember correctly if SECTWO is set to yes at IPL then it remembers it 
until the next IPL and if you change it to no it won't work until the next IPL.

Thanks:)



From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Tuesday, May 12, 2020 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TMSINIT

EXTERNAL:  Do not open attachments or click on links unless you recognize and 
trust the sender.

IIRC it's the password used when you installed CA-1, one of the usermods, some 
sites use the default.
it should be in a usermod or sampjcl member


Carmen Vitullo

- Original Message -

From: "Dean Nai" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, May 12, 2020 12:30:23 PM
Subject: TMSINIT

I know this isn't a Z question but people on here have knowledge about most 
things.


I'm trying to run a CA-1 TMSINIT outside of an IPL and I'm getting this 
message. Nobody here knows what to reply. Any thoughts.


IEFTMS32 - ENTER USERID AUTHORIZED TO RUN TMSINIT

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

[Brian Fraser]

We reply the TSO USERID of the Operator that started TMSINIT. It will then
ask them to enter their password.

You can set the SECWTO option in the TMOOPTxx member of CTAPOPTN to NO if
you do not want to validate that the operator executing TMSINIT as a
started task has the correct level of authority.

On Wed, 13 May 2020 at 01:30, Nai, Dean  wrote:

> I know this isn't a Z question but people on here have knowledge about
> most things.
>
>
> I'm trying to run a CA-1 TMSINIT outside of an IPL and I'm getting this
> message. Nobody here knows what to reply. Any thoughts.
>
>
> IEFTMS32 - ENTER USERID AUTHORIZED TO RUN TMSINIT
>
> --
> 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: TMSINIT

[Lizette Koehler]

If you are a high enough version of CA1.  There s now a TMSSEC00 member that
describes your CA IDs and what level of authority they have.

You might want to check it

And there is another entry TMSOPT00 which contains your Master CA1 Password.

Ask your security team if they changed anything.

There are some good write ups in the CA 1 Manuals

Lizette
  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Nai, Dean
Sent: Tuesday, May 12, 2020 10:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: TMSINIT

I know this isn't a Z question but people on here have knowledge about most
things.


I'm trying to run a CA-1 TMSINIT outside of an IPL and I'm getting this
message. Nobody here knows what to reply. Any thoughts.


IEFTMS32 - ENTER USERID AUTHORIZED TO RUN TMSINIT

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

[Carmen Vitullo]

IIRC it's the password used when you installed CA-1, one of the usermods, some 
sites use the default. 
it should be in a usermod or sampjcl member 


Carmen Vitullo 

- Original Message -

From: "Dean Nai"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, May 12, 2020 12:30:23 PM 
Subject: TMSINIT 

I know this isn't a Z question but people on here have knowledge about most 
things. 


I'm trying to run a CA-1 TMSINIT outside of an IPL and I'm getting this 
message. Nobody here knows what to reply. Any thoughts. 


IEFTMS32 - ENTER USERID AUTHORIZED TO RUN TMSINIT 

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

TMSINIT

[Nai, Dean]

I know this isn't a Z question but people on here have knowledge about most 
things.


I'm trying to run a CA-1 TMSINIT outside of an IPL and I'm getting this 
message. Nobody here knows what to reply. Any thoughts.


IEFTMS32 - ENTER USERID AUTHORIZED TO RUN TMSINIT

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

Re: 3270 terminals: CUT vs. DFT

[Mike Schwab]

System 34/36/38/ AS/400 use the 5251 which is very similar.  And Dec
VT (100+) series that most emulators also support, with ANSI control
sequences.

On Tue, May 12, 2020 at 3:06 PM Martin Packer  wrote:
>
> This has all got me re-examining the 3270 data stream and wondering...
>
> ... Did anything else ever use the 3270 data stream - other than IBM
> mainframe operating systems?
>
> It's such a nice efficient data stream that one might like to use it from
> other platforms. But I wouldn't know how to set up a server x3270 could
> talk to.
>
> Cheers, Martin
>
> Martin Packer
>
> zChampion, Systems Investigator & Performance Troubleshooter, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog: https://mainframeperformancetopics.com
>
> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or
>
> https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2
>
>
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
>
>
> From:   William Donzelli 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   12/05/2020 15:53
> Subject:[EXTERNAL] Re: 3270 terminals: CUT vs. DFT
> Sent by:IBM Mainframe Discussion List 
>
>
>
> For that matter, are there any references to how many terminals IBM
> produced per model, from the 1015 to InfoWindows (or whatever was
> last)? I have always wondered in IBM was the largest maker of
> terminals ever.
>
> --
> Will
>
> On Tue, May 12, 2020 at 10:45 AM Seymour J Metz  wrote:
> >
> > I saw a lot more 3180s than I did 3278, but as I recall that was also
> CUT. What kind of markwt penetration did InfoWindow have?
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=2_dLQ99XMMi7XL9AydcJIFMrlzJqYI4Ngsl7w_tE95U=aqToAM4vGOYPA5irjNsqtaoaOFO7gN2o9nM0HNr8PBo=
>
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of zMan [zedgarhoo...@gmail.com]
> > Sent: Tuesday, May 12, 2020 10:27 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: 3270 terminals: CUT vs. DFT
> >
> > I'd suggest that most terminals were 3278s, so his statement stands. But
> > we'll never know.
> >
> > On Mon, May 11, 2020 at 3:28 PM Seymour J Metz  wrote:
> >
> > > > Most 3270 terminals seem to be of the (simpler) CUT variant.
> > >
> > > I doubt it. Certainly all of these are DFT.
> > >
> > > • IBM 3179 G Color Graphic Display Station
> > > • IBM 3192 G Color Graphics Display Station
> > > • IBM 3193 Display Station
> > > • IBM 3194 Display Terminal
> > > • IBM 3290 Information Panel
> > > • IBM 3270 Personal Computer.
> > >
> > > Does anybody know whether any of the InfoWindow displays are CUT, and,
> if
> > > so, which?
> > >
> > > I suspect that it will be easier to modify, e.g., x3270 to support the
> > > 3290 features than to implement DFT without help from IBM, but
> bitsavers
> > > does have some 3174 and 3274 CE manuals, and maybe one of them has
> what you
> > > need.
> > >
> > >
> > >
> > > --
> > > Shmuel (Seymour J.) Metz
> > >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=2_dLQ99XMMi7XL9AydcJIFMrlzJqYI4Ngsl7w_tE95U=aqToAM4vGOYPA5irjNsqtaoaOFO7gN2o9nM0HNr8PBo=
>
> > >
> > > 
> > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf
> > > of Alexander Huemer [alexander.hue...@xx.vu]
> > > Sent: Monday, May 11, 2020 2:16 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: 3270 terminals: CUT vs. DFT
> > >
> > > Hi
> > >
> > > I have a 3290 terminal that I'd like to put to some use. See email
> > > thread 'Talking to 3270 terminals?' that I started Jan 14.
> > > Somebody then pointed me to oec[1], which is an awesome project. I
> have
> > > built the hardware interface that is required to talk to a 3270
> terminal
> > > on the hardware level. A picture of the interface and a video of the
> > > terminal can be found at [2].
> > >
> > > Now, the friendly person who created oec says that the 3290 is a so
> > > called DFT (Distributed Function Terminal), in contrast to a CUT
> > > (Control Unit Terminal). Most 3270 terminals seem to be of the
> (simpler)
> > > CUT variant. oec only works with CUT terminals. Extending the
> > > functionality to enable it to work with DFT terminals isn't trivial.
> > >
> > > Does anybody on the list here know of additional documentation besides
> > > what's mentioned at [3] that could be helpful to implement DFT
> support?
> > >
> > > What would also be very helpful is a protocol trace of any kind of the
> > > communication between a 3174 and a DFT terminal.
> > >
> > > -Alex
> > >
> > > [1]
> > >
> 

Re: 3270 terminals: CUT vs. DFT

[Alexander Huemer]

At my employer in 1999 there were almost exclusively monochrome 3192, 
besides a few Memorex Telex terminals that were used as the VM/ESA and 
VSE/ESA admin consoles.
Not sure of the model number of those.

-Alex

On Tue, May 12, 2020 at 02:45:13PM +, Seymour J Metz wrote:
> I saw a lot more 3180s than I did 3278, but as I recall that was also CUT. 
> What kind of markwt penetration did InfoWindow have?
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> zMan [zedgarhoo...@gmail.com]
> Sent: Tuesday, May 12, 2020 10:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: 3270 terminals: CUT vs. DFT
> 
> I'd suggest that most terminals were 3278s, so his statement stands.  But
> we'll never know.
> 
> On Mon, May 11, 2020 at 3:28 PM Seymour J Metz  wrote:
> 
> > > Most 3270 terminals seem to be of the (simpler) CUT variant.
> >
> > I doubt it. Certainly all of these are DFT.
> >
> > • IBM 3179 G Color Graphic Display Station
> > • IBM 3192 G Color Graphics Display Station
> > • IBM 3193 Display Station
> > • IBM 3194 Display Terminal
> > • IBM 3290 Information Panel
> > • IBM 3270 Personal Computer.
> >
> > Does anybody know whether any of the InfoWindow displays are CUT, and, if
> > so, which?
> >
> > I suspect that it will be easier to modify, e.g., x3270 to support the
> > 3290 features than to implement DFT without help from IBM, but bitsavers
> > does have some 3174 and 3274 CE manuals, and maybe one of them has what you
> > need.
> >
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Alexander Huemer [alexander.hue...@xx.vu]
> > Sent: Monday, May 11, 2020 2:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: 3270 terminals: CUT vs. DFT
> >
> > Hi
> >
> > I have a 3290 terminal that I'd like to put to some use. See email
> > thread 'Talking to 3270 terminals?' that I started Jan 14.
> > Somebody then pointed me to oec[1], which is an awesome project. I have
> > built the hardware interface that is required to talk to a 3270 terminal
> > on the hardware level. A picture of the interface and a video of the
> > terminal can be found at [2].
> >
> > Now, the friendly person who created oec says that the 3290 is a so
> > called DFT (Distributed Function Terminal), in contrast to a CUT
> > (Control Unit Terminal). Most 3270 terminals seem to be of the (simpler)
> > CUT variant. oec only works with CUT terminals. Extending the
> > functionality to enable it to work with DFT terminals isn't trivial.
> >
> > Does anybody on the list here know of additional documentation besides
> > what's mentioned at [3] that could be helpful to implement DFT support?
> >
> > What would also be very helpful is a protocol trace of any kind of the
> > communication between a 3174 and a DFT terminal.
> >
> > -Alex
> >
> > [1]
> > https://secure-web.cisco.com/1NnRTMD_PTNE56hcPN3Zoil25kvZDUUK_aipLBMH0L1wILqqABd8VqLfLufezSPeE_Fl4x00j7t4NfyMBkNjiG9PZJVFzcisGkVw2zDksozehbGrT1dQrE0Ab77RISHAxIQOxnUnRrTtoTrsSrrPsu0jB_gX0Wu7yY3WQm4OWspA270WOpKiWNPsOuRmstQQpzBMsjKSh2liu3id4kuAg3n_Anb4G2bBwbb4hvDUDYwgDt6oVZYjuuMmpgqXD6BoDKPz8h13B3FNewEGGG-ZmkWrk8Ij2IMQB2BwK-56UDvG1tFuhjaZRmy8w4zpndnP-EtTI3GVvakjoOfX9TfnAX8Jkf44VijzUU9DY-2nBQHJtCnhDUEwfezo4317R__cJdwXO34VGrBQVzqETM7RjUNDyRR0uqgmmjgiazA_-Er6FIi6yH2m1euIXZa34S3xhYqqtFwfDa_ElLFDmsmOI2Q/https%3A%2F%2Fgithub.com%2Flowobservable%2Foec
> > [2]
> > https://secure-web.cisco.com/1pSKlPn7aH5BVsfyddjr3HyN_XBjHGssIdgXlLr5CxccG7hAYb_O5qPKiIdRoApG1elM2Wd9QHZu8E-Sc0Xs6zVv0qISCsksY98nFPIe4uoRAieXyzi8hgly4lpVu7klwwS9g8wH1b4FfatJ0HsF1a8dfDnI-6l3OxLz3Jy338dAlfK2uq6u0v4C4M0d81GHudLtr_VFDQylLJhpec2y2uLiLbGwjSHUH35bLwEyjNd3ieBfIBxmlVuhlb3l46ibyiWGouVr4Ik0Gv2xmSL7s7rC35o3kYxwRawP7KL4ODxWKDeikbWKj0j2V8_T4TKfXlwLvH-jYtZ5zOnLAg4DNyo6HSLYXAp0Zv235Je698lh_uza4HemJsGDS2-uZNyNE1cuP43_FPksOmUrw6l7Hb2EzSd_Dthu4mEIpdYKZ3QVTjXl6NCaXqVR0EOhzTiAG/https%3A%2F%2Fahuemer.xx.vu%2Fvolatile%2F2020-05-11-P6C1Wc3u1wU%2F
> > [3]
> > https://secure-web.cisco.com/1lc47FG678Pn52RvDToQE0dXvwOnbKbGRbN6-Isvy6vMB2s_1yJBYWRZduvax-epmacIYbcnUCmIDLFWsbAlx_fWds6f40LanIVAYPxdce1BHtR1n3vOrRj5HYg2a7X0OUGDmyQo5lbNDPJe4_1ZWQef0LNTjfaSRCzPpj3tZII47tuuxs28-fTaGV4MDSgtO9jaD-f7yC5zLnri6JD3NrMLNk_lXBXHB_Hk3br48XLWLuwVAaggwCCR45N5Hu_758ek0a2pzvPqte89y2l8WKPiWo5YcyZ5zBqkVcMMN8_c2GGaFmeCl8oAT8xZPna0HAe9_wOfiXZhazeqZNXgkLTtp5SIkDA-w89OFkBUEiZ7zDJOBlPKrQImvQ80P_BNvWDFPNOV4FkQzE23fVo7OCcs8cz0F3DWBQ9Vv8LZrlyYfNFgscrOK-BreBPLoDCZPagTbpFJQBCNrgWM8LyVDwQ/https%3A%2F%2Fgithub.com%2Flowobservable%2Fcoax%2Fblob%2Fprotocol%2Fprotocol%2Fprotocol.md
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > 

Re: Developers say Google's Go is 'most sought after' programming language of 2020

[Jack J. Woehr]

On 5/12/20 9:28 AM, Seymour J Metz wrote:

  I also want them in Linux for Z, but that may already be here.


z/Linux has pretty much everything. Did some heavy lifting there. What 
wasn't there I could build, with some work.


Essence of Open Source: You are part of the solution.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: IGDSMSxx setting PDSE_VERSION(2)

[Tom Marchant]

Radoslaw,
What do you mean? Are you referring to running with PDSESHARING(NORMAL)?

Is it documented anywhere that a PDSE can be safely shared outside a 
SYSPLEX when running PDSESHARING(EXTENDED)?

-- 
Tom Marchant

On Tue, 12 May 2020 17:02:23 +0200, R.S. wrote:

>Yes, I'm aware of that. However I would like to have it changed.
>
>BTW: DASD isolation is safe way, but not the only one. Of course it is
>still very bad idea to share PDSE, with very few very specific and
>cumbersome exceptions. Nevermind.
>
>--
>Radoslaw Skorupka
>Lodz, Poland
>
>
>W dniu 12.05.2020 o 16:56, Knutson, Samuel pisze:
>> #2 The only safe way to do this is not to share DASD outside the scope of a 
>> Sysplex.

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

Re: Developers say Google's Go is 'most sought after' programming language of 2020

[Seymour J Metz]

For example, the current Perl is 5.30, not 5.24.

Not z/OS in the same sense that Solaris in a virtual machine is not z/VM; the 
code that z/OS runs in a container is Linux code. I'd like the more common 
languages available in a form interoperable with at least batch, TSO and OMVS 
applications. I also want them in Linux for Z, but that may already be here.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Timothy Sipples [sipp...@sg.ibm.com]
Sent: Tuesday, May 12, 2020 12:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Developers say Google's Go is 'most sought after' programming 
language of 2020

Shmuel Metz wrote:
>The problem is that some of those are incomplete, not z/OS,
>or not up to date.

1. Would you like to be more specific? (And I don't know what you mean by
"not z/OS." I answered specifically, exclusively for z/OS.)

2. Have you tried fixing the specific issues?

- - - - - - - - - -
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: 3270 terminals: CUT vs. DFT

[Martin Packer]

I think customers really liked InfoWindow because they were the first 
terminals to offer a 3-year guarantee. IIRC that was a big selling point.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


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



From:   Seymour J Metz 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/05/2020 15:46
Subject:[EXTERNAL] Re: 3270 terminals: CUT vs. DFT
Sent by:IBM Mainframe Discussion List 



I saw a lot more 3180s than I did 3278, but as I recall that was also CUT. 
What kind of markwt penetration did InfoWindow have?


--
Shmuel (Seymour J.) Metz
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=744ZQE7RpiXzUnS2QxR-S60qEJm7s_SEijnDCsOCEZ4=9xNNTmnRYTwQf4fyyB-lW-Im9M3txhTk10eIHF5kfZc=
 



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf 
of zMan [zedgarhoo...@gmail.com]
Sent: Tuesday, May 12, 2020 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 3270 terminals: CUT vs. DFT

I'd suggest that most terminals were 3278s, so his statement stands.  But
we'll never know.

On Mon, May 11, 2020 at 3:28 PM Seymour J Metz  wrote:

> > Most 3270 terminals seem to be of the (simpler) CUT variant.
>
> I doubt it. Certainly all of these are DFT.
>
> • IBM 3179 G Color Graphic Display Station
> • IBM 3192 G Color Graphics Display Station
> • IBM 3193 Display Station
> • IBM 3194 Display Terminal
> • IBM 3290 Information Panel
> • IBM 3270 Personal Computer.
>
> Does anybody know whether any of the InfoWindow displays are CUT, and, 
if
> so, which?
>
> I suspect that it will be easier to modify, e.g., x3270 to support the
> 3290 features than to implement DFT without help from IBM, but bitsavers
> does have some 3174 and 3274 CE manuals, and maybe one of them has what 
you
> need.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=744ZQE7RpiXzUnS2QxR-S60qEJm7s_SEijnDCsOCEZ4=9xNNTmnRYTwQf4fyyB-lW-Im9M3txhTk10eIHF5kfZc=
 

>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Alexander Huemer [alexander.hue...@xx.vu]
> Sent: Monday, May 11, 2020 2:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 3270 terminals: CUT vs. DFT
>
> Hi
>
> I have a 3290 terminal that I'd like to put to some use. See email
> thread 'Talking to 3270 terminals?' that I started Jan 14.
> Somebody then pointed me to oec[1], which is an awesome project. I have
> built the hardware interface that is required to talk to a 3270 terminal
> on the hardware level. A picture of the interface and a video of the
> terminal can be found at [2].
>
> Now, the friendly person who created oec says that the 3290 is a so
> called DFT (Distributed Function Terminal), in contrast to a CUT
> (Control Unit Terminal). Most 3270 terminals seem to be of the (simpler)
> CUT variant. oec only works with CUT terminals. Extending the
> functionality to enable it to work with DFT terminals isn't trivial.
>
> Does anybody on the list here know of additional documentation besides
> what's mentioned at [3] that could be helpful to implement DFT support?
>
> What would also be very helpful is a protocol trace of any kind of the
> communication between a 3174 and a DFT terminal.
>
> -Alex
>
> [1]
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_1NnRTMD-5FPTNE56hcPN3Zoil25kvZDUUK-5FaipLBMH0L1wILqqABd8VqLfLufezSPeE-5FFl4x00j7t4NfyMBkNjiG9PZJVFzcisGkVw2zDksozehbGrT1dQrE0Ab77RISHAxIQOxnUnRrTtoTrsSrrPsu0jB-5FgX0Wu7yY3WQm4OWspA270WOpKiWNPsOuRmstQQpzBMsjKSh2liu3id4kuAg3n-5FAnb4G2bBwbb4hvDUDYwgDt6oVZYjuuMmpgqXD6BoDKPz8h13B3FNewEGGG-2DZmkWrk8Ij2IMQB2BwK-2D56UDvG1tFuhjaZRmy8w4zpndnP-2DEtTI3GVvakjoOfX9TfnAX8Jkf44VijzUU9DY-2D2nBQHJtCnhDUEwfezo4317R-5F-5FcJdwXO34VGrBQVzqETM7RjUNDyRR0uqgmmjgiazA-5F-2DEr6FIi6yH2m1euIXZa34S3xhYqqtFwfDa-5FElLFDmsmOI2Q_https-253A-252F-252Fgithub.com-252Flowobservable-252Foec=DwIF-g=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=744ZQE7RpiXzUnS2QxR-S60qEJm7s_SEijnDCsOCEZ4=6nv5bSP_G3YnjlrYfP0dWQDIHGY4WK3hN_ZOYEoXyOs=
 

> [2]
> 

Re: 3270 terminals: CUT vs. DFT

[Martin Packer]

This has all got me re-examining the 3270 data stream and wondering...

... Did anything else ever use the 3270 data stream - other than IBM 
mainframe operating systems?

It's such a nice efficient data stream that one might like to use it from 
other platforms. But I wouldn't know how to set up a server x3270 could 
talk to.

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


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



From:   William Donzelli 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/05/2020 15:53
Subject:[EXTERNAL] Re: 3270 terminals: CUT vs. DFT
Sent by:IBM Mainframe Discussion List 



For that matter, are there any references to how many terminals IBM
produced per model, from the 1015 to InfoWindows (or whatever was
last)? I have always wondered in IBM was the largest maker of
terminals ever.

--
Will

On Tue, May 12, 2020 at 10:45 AM Seymour J Metz  wrote:
>
> I saw a lot more 3180s than I did 3278, but as I recall that was also 
CUT. What kind of markwt penetration did InfoWindow have?
>
>
> --
> Shmuel (Seymour J.) Metz
> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=2_dLQ99XMMi7XL9AydcJIFMrlzJqYI4Ngsl7w_tE95U=aqToAM4vGOYPA5irjNsqtaoaOFO7gN2o9nM0HNr8PBo=
 

>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf 
of zMan [zedgarhoo...@gmail.com]
> Sent: Tuesday, May 12, 2020 10:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: 3270 terminals: CUT vs. DFT
>
> I'd suggest that most terminals were 3278s, so his statement stands. But
> we'll never know.
>
> On Mon, May 11, 2020 at 3:28 PM Seymour J Metz  wrote:
>
> > > Most 3270 terminals seem to be of the (simpler) CUT variant.
> >
> > I doubt it. Certainly all of these are DFT.
> >
> > • IBM 3179 G Color Graphic Display Station
> > • IBM 3192 G Color Graphics Display Station
> > • IBM 3193 Display Station
> > • IBM 3194 Display Terminal
> > • IBM 3290 Information Panel
> > • IBM 3270 Personal Computer.
> >
> > Does anybody know whether any of the InfoWindow displays are CUT, and, 
if
> > so, which?
> >
> > I suspect that it will be easier to modify, e.g., x3270 to support the
> > 3290 features than to implement DFT without help from IBM, but 
bitsavers
> > does have some 3174 and 3274 CE manuals, and maybe one of them has 
what you
> > need.
> >
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > 
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=2_dLQ99XMMi7XL9AydcJIFMrlzJqYI4Ngsl7w_tE95U=aqToAM4vGOYPA5irjNsqtaoaOFO7gN2o9nM0HNr8PBo=
 

> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
behalf
> > of Alexander Huemer [alexander.hue...@xx.vu]
> > Sent: Monday, May 11, 2020 2:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: 3270 terminals: CUT vs. DFT
> >
> > Hi
> >
> > I have a 3290 terminal that I'd like to put to some use. See email
> > thread 'Talking to 3270 terminals?' that I started Jan 14.
> > Somebody then pointed me to oec[1], which is an awesome project. I 
have
> > built the hardware interface that is required to talk to a 3270 
terminal
> > on the hardware level. A picture of the interface and a video of the
> > terminal can be found at [2].
> >
> > Now, the friendly person who created oec says that the 3290 is a so
> > called DFT (Distributed Function Terminal), in contrast to a CUT
> > (Control Unit Terminal). Most 3270 terminals seem to be of the 
(simpler)
> > CUT variant. oec only works with CUT terminals. Extending the
> > functionality to enable it to work with DFT terminals isn't trivial.
> >
> > Does anybody on the list here know of additional documentation besides
> > what's mentioned at [3] that could be helpful to implement DFT 
support?
> >
> > What would also be very helpful is a protocol trace of any kind of the
> > communication between a 3174 and a DFT terminal.
> >
> > -Alex
> >
> > [1]
> > 

Re: IGDSMSxx setting PDSE_VERSION(2)

[R.S.]

Yes, I'm aware of that. However I would like to have it changed.

BTW: DASD isolation is safe way, but not the only one. Of course it is 
still very bad idea to share PDSE, with very few very specific and 
cumbersome exceptions. Nevermind.


--
Radoslaw Skorupka
Lodz, Poland






W dniu 12.05.2020 o 16:56, Knutson, Samuel pisze:

#2 The only safe way to do this is not to share DASD outside the scope of a 
Sysplex.   I don't expect that to change.  Having at least System Test, 
Development and Production Sysplex that completely isolate DASD lets you get 
the most benefits from isolation of those types of workloads.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Tuesday, May 12, 2020 10:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IGDSMSxx setting PDSE_VERSION(2)

My humble opinion:
Everybody who want or really need PDSE v2 will create such dataset explicitly 
by specifying DSNTYPE=(LIBRARY,2). That's OK.

You want to create PDSE v2 by default. This is the best way to find out which system 
components or application still not tolerate new PDSE flavour. But this is hard way. It 
can be nice when application will refuse to open new dataset, but things may go worse way 
when the problem occur in the middle of "landing the plane".

BTW: The only case when I needed PDSE v2 was huge PTF (for WAS), which exceeded 
the limit of member size of SMPPTS. However it was before PDSE
v2 was born so I switched to plain old PDS.
PDS members are not limited in size, however PDS itself is limited to 64k TRK 
which is much less that limit of member size for PDSE v2.

And I'm still missing two things:
1. Multi-volume PDSE.
2. PDSE sharing across the sysplex.
It can be even "by command" sharing like "F PDSE=SYS1.TEST1,CLOSE" on one 
system to be able to open it on another system.
It is much better than educate folks to not share PDSE's.

--
Radoslaw Skorupka
Lodz, Poland

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it

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




==

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: IGDSMSxx setting PDSE_VERSION(2)

[Knutson, Samuel]

#2 The only safe way to do this is not to share DASD outside the scope of a 
Sysplex.   I don't expect that to change.  Having at least System Test, 
Development and Production Sysplex that completely isolate DASD lets you get 
the most benefits from isolation of those types of workloads.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of R.S.
Sent: Tuesday, May 12, 2020 10:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IGDSMSxx setting PDSE_VERSION(2)

My humble opinion:
Everybody who want or really need PDSE v2 will create such dataset explicitly 
by specifying DSNTYPE=(LIBRARY,2). That's OK.

You want to create PDSE v2 by default. This is the best way to find out which 
system components or application still not tolerate new PDSE flavour. But this 
is hard way. It can be nice when application will refuse to open new dataset, 
but things may go worse way when the problem occur in the middle of "landing 
the plane".

BTW: The only case when I needed PDSE v2 was huge PTF (for WAS), which exceeded 
the limit of member size of SMPPTS. However it was before PDSE
v2 was born so I switched to plain old PDS.
PDS members are not limited in size, however PDS itself is limited to 64k TRK 
which is much less that limit of member size for PDSE v2.

And I'm still missing two things:
1. Multi-volume PDSE.
2. PDSE sharing across the sysplex.
It can be even "by command" sharing like "F PDSE=SYS1.TEST1,CLOSE" on one 
system to be able to open it on another system.
It is much better than educate folks to not share PDSE's.

--
Radoslaw Skorupka
Lodz, Poland

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it

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

Re: 3270 terminals: CUT vs. DFT

[William Donzelli]

For that matter, are there any references to how many terminals IBM
produced per model, from the 1015 to InfoWindows (or whatever was
last)? I have always wondered in IBM was the largest maker of
terminals ever.

--
Will

On Tue, May 12, 2020 at 10:45 AM Seymour J Metz  wrote:
>
> I saw a lot more 3180s than I did 3278, but as I recall that was also CUT. 
> What kind of markwt penetration did InfoWindow have?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> zMan [zedgarhoo...@gmail.com]
> Sent: Tuesday, May 12, 2020 10:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: 3270 terminals: CUT vs. DFT
>
> I'd suggest that most terminals were 3278s, so his statement stands.  But
> we'll never know.
>
> On Mon, May 11, 2020 at 3:28 PM Seymour J Metz  wrote:
>
> > > Most 3270 terminals seem to be of the (simpler) CUT variant.
> >
> > I doubt it. Certainly all of these are DFT.
> >
> > • IBM 3179 G Color Graphic Display Station
> > • IBM 3192 G Color Graphics Display Station
> > • IBM 3193 Display Station
> > • IBM 3194 Display Terminal
> > • IBM 3290 Information Panel
> > • IBM 3270 Personal Computer.
> >
> > Does anybody know whether any of the InfoWindow displays are CUT, and, if
> > so, which?
> >
> > I suspect that it will be easier to modify, e.g., x3270 to support the
> > 3290 features than to implement DFT without help from IBM, but bitsavers
> > does have some 3174 and 3274 CE manuals, and maybe one of them has what you
> > need.
> >
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Alexander Huemer [alexander.hue...@xx.vu]
> > Sent: Monday, May 11, 2020 2:16 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: 3270 terminals: CUT vs. DFT
> >
> > Hi
> >
> > I have a 3290 terminal that I'd like to put to some use. See email
> > thread 'Talking to 3270 terminals?' that I started Jan 14.
> > Somebody then pointed me to oec[1], which is an awesome project. I have
> > built the hardware interface that is required to talk to a 3270 terminal
> > on the hardware level. A picture of the interface and a video of the
> > terminal can be found at [2].
> >
> > Now, the friendly person who created oec says that the 3290 is a so
> > called DFT (Distributed Function Terminal), in contrast to a CUT
> > (Control Unit Terminal). Most 3270 terminals seem to be of the (simpler)
> > CUT variant. oec only works with CUT terminals. Extending the
> > functionality to enable it to work with DFT terminals isn't trivial.
> >
> > Does anybody on the list here know of additional documentation besides
> > what's mentioned at [3] that could be helpful to implement DFT support?
> >
> > What would also be very helpful is a protocol trace of any kind of the
> > communication between a 3174 and a DFT terminal.
> >
> > -Alex
> >
> > [1]
> > https://secure-web.cisco.com/1NnRTMD_PTNE56hcPN3Zoil25kvZDUUK_aipLBMH0L1wILqqABd8VqLfLufezSPeE_Fl4x00j7t4NfyMBkNjiG9PZJVFzcisGkVw2zDksozehbGrT1dQrE0Ab77RISHAxIQOxnUnRrTtoTrsSrrPsu0jB_gX0Wu7yY3WQm4OWspA270WOpKiWNPsOuRmstQQpzBMsjKSh2liu3id4kuAg3n_Anb4G2bBwbb4hvDUDYwgDt6oVZYjuuMmpgqXD6BoDKPz8h13B3FNewEGGG-ZmkWrk8Ij2IMQB2BwK-56UDvG1tFuhjaZRmy8w4zpndnP-EtTI3GVvakjoOfX9TfnAX8Jkf44VijzUU9DY-2nBQHJtCnhDUEwfezo4317R__cJdwXO34VGrBQVzqETM7RjUNDyRR0uqgmmjgiazA_-Er6FIi6yH2m1euIXZa34S3xhYqqtFwfDa_ElLFDmsmOI2Q/https%3A%2F%2Fgithub.com%2Flowobservable%2Foec
> > [2]
> > https://secure-web.cisco.com/1pSKlPn7aH5BVsfyddjr3HyN_XBjHGssIdgXlLr5CxccG7hAYb_O5qPKiIdRoApG1elM2Wd9QHZu8E-Sc0Xs6zVv0qISCsksY98nFPIe4uoRAieXyzi8hgly4lpVu7klwwS9g8wH1b4FfatJ0HsF1a8dfDnI-6l3OxLz3Jy338dAlfK2uq6u0v4C4M0d81GHudLtr_VFDQylLJhpec2y2uLiLbGwjSHUH35bLwEyjNd3ieBfIBxmlVuhlb3l46ibyiWGouVr4Ik0Gv2xmSL7s7rC35o3kYxwRawP7KL4ODxWKDeikbWKj0j2V8_T4TKfXlwLvH-jYtZ5zOnLAg4DNyo6HSLYXAp0Zv235Je698lh_uza4HemJsGDS2-uZNyNE1cuP43_FPksOmUrw6l7Hb2EzSd_Dthu4mEIpdYKZ3QVTjXl6NCaXqVR0EOhzTiAG/https%3A%2F%2Fahuemer.xx.vu%2Fvolatile%2F2020-05-11-P6C1Wc3u1wU%2F
> > [3]
> > https://secure-web.cisco.com/1lc47FG678Pn52RvDToQE0dXvwOnbKbGRbN6-Isvy6vMB2s_1yJBYWRZduvax-epmacIYbcnUCmIDLFWsbAlx_fWds6f40LanIVAYPxdce1BHtR1n3vOrRj5HYg2a7X0OUGDmyQo5lbNDPJe4_1ZWQef0LNTjfaSRCzPpj3tZII47tuuxs28-fTaGV4MDSgtO9jaD-f7yC5zLnri6JD3NrMLNk_lXBXHB_Hk3br48XLWLuwVAaggwCCR45N5Hu_758ek0a2pzvPqte89y2l8WKPiWo5YcyZ5zBqkVcMMN8_c2GGaFmeCl8oAT8xZPna0HAe9_wOfiXZhazeqZNXgkLTtp5SIkDA-w89OFkBUEiZ7zDJOBlPKrQImvQ80P_BNvWDFPNOV4FkQzE23fVo7OCcs8cz0F3DWBQ9Vv8LZrlyYfNFgscrOK-BreBPLoDCZPagTbpFJQBCNrgWM8LyVDwQ/https%3A%2F%2Fgithub.com%2Flowobservable%2Fcoax%2Fblob%2Fprotocol%2Fprotocol%2Fprotocol.md
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > 

Re: IGDSMSxx setting PDSE_VERSION(2)

[R.S.]

My humble opinion:
Everybody who want or really need PDSE v2 will create such dataset 
explicitly by specifying DSNTYPE=(LIBRARY,2). That's OK.


You want to create PDSE v2 by default. This is the best way to find out 
which system components or application still not tolerate new PDSE 
flavour. But this is hard way. It can be nice when application will 
refuse to open new dataset, but things may go worse way when the problem 
occur in the middle of "landing the plane".


BTW: The only case when I needed PDSE v2 was huge PTF (for WAS), which 
exceeded the limit of member size of SMPPTS. However it was before PDSE 
v2 was born so I switched to plain old PDS.
PDS members are not limited in size, however PDS itself is limited to 
64k TRK which is much less that limit of member size for PDSE v2.


And I'm still missing two things:
1. Multi-volume PDSE.
2. PDSE sharing across the sysplex.
It can be even "by command" sharing like "F PDSE=SYS1.TEST1,CLOSE" on 
one system to be able to open it on another system.

It is much better than educate folks to not share PDSE's.

--
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: 3270 terminals: CUT vs. DFT

[Seymour J Metz]

I saw a lot more 3180s than I did 3278, but as I recall that was also CUT. What 
kind of markwt penetration did InfoWindow have?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
zMan [zedgarhoo...@gmail.com]
Sent: Tuesday, May 12, 2020 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 3270 terminals: CUT vs. DFT

I'd suggest that most terminals were 3278s, so his statement stands.  But
we'll never know.

On Mon, May 11, 2020 at 3:28 PM Seymour J Metz  wrote:

> > Most 3270 terminals seem to be of the (simpler) CUT variant.
>
> I doubt it. Certainly all of these are DFT.
>
> • IBM 3179 G Color Graphic Display Station
> • IBM 3192 G Color Graphics Display Station
> • IBM 3193 Display Station
> • IBM 3194 Display Terminal
> • IBM 3290 Information Panel
> • IBM 3270 Personal Computer.
>
> Does anybody know whether any of the InfoWindow displays are CUT, and, if
> so, which?
>
> I suspect that it will be easier to modify, e.g., x3270 to support the
> 3290 features than to implement DFT without help from IBM, but bitsavers
> does have some 3174 and 3274 CE manuals, and maybe one of them has what you
> need.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Alexander Huemer [alexander.hue...@xx.vu]
> Sent: Monday, May 11, 2020 2:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 3270 terminals: CUT vs. DFT
>
> Hi
>
> I have a 3290 terminal that I'd like to put to some use. See email
> thread 'Talking to 3270 terminals?' that I started Jan 14.
> Somebody then pointed me to oec[1], which is an awesome project. I have
> built the hardware interface that is required to talk to a 3270 terminal
> on the hardware level. A picture of the interface and a video of the
> terminal can be found at [2].
>
> Now, the friendly person who created oec says that the 3290 is a so
> called DFT (Distributed Function Terminal), in contrast to a CUT
> (Control Unit Terminal). Most 3270 terminals seem to be of the (simpler)
> CUT variant. oec only works with CUT terminals. Extending the
> functionality to enable it to work with DFT terminals isn't trivial.
>
> Does anybody on the list here know of additional documentation besides
> what's mentioned at [3] that could be helpful to implement DFT support?
>
> What would also be very helpful is a protocol trace of any kind of the
> communication between a 3174 and a DFT terminal.
>
> -Alex
>
> [1]
> https://secure-web.cisco.com/1NnRTMD_PTNE56hcPN3Zoil25kvZDUUK_aipLBMH0L1wILqqABd8VqLfLufezSPeE_Fl4x00j7t4NfyMBkNjiG9PZJVFzcisGkVw2zDksozehbGrT1dQrE0Ab77RISHAxIQOxnUnRrTtoTrsSrrPsu0jB_gX0Wu7yY3WQm4OWspA270WOpKiWNPsOuRmstQQpzBMsjKSh2liu3id4kuAg3n_Anb4G2bBwbb4hvDUDYwgDt6oVZYjuuMmpgqXD6BoDKPz8h13B3FNewEGGG-ZmkWrk8Ij2IMQB2BwK-56UDvG1tFuhjaZRmy8w4zpndnP-EtTI3GVvakjoOfX9TfnAX8Jkf44VijzUU9DY-2nBQHJtCnhDUEwfezo4317R__cJdwXO34VGrBQVzqETM7RjUNDyRR0uqgmmjgiazA_-Er6FIi6yH2m1euIXZa34S3xhYqqtFwfDa_ElLFDmsmOI2Q/https%3A%2F%2Fgithub.com%2Flowobservable%2Foec
> [2]
> https://secure-web.cisco.com/1pSKlPn7aH5BVsfyddjr3HyN_XBjHGssIdgXlLr5CxccG7hAYb_O5qPKiIdRoApG1elM2Wd9QHZu8E-Sc0Xs6zVv0qISCsksY98nFPIe4uoRAieXyzi8hgly4lpVu7klwwS9g8wH1b4FfatJ0HsF1a8dfDnI-6l3OxLz3Jy338dAlfK2uq6u0v4C4M0d81GHudLtr_VFDQylLJhpec2y2uLiLbGwjSHUH35bLwEyjNd3ieBfIBxmlVuhlb3l46ibyiWGouVr4Ik0Gv2xmSL7s7rC35o3kYxwRawP7KL4ODxWKDeikbWKj0j2V8_T4TKfXlwLvH-jYtZ5zOnLAg4DNyo6HSLYXAp0Zv235Je698lh_uza4HemJsGDS2-uZNyNE1cuP43_FPksOmUrw6l7Hb2EzSd_Dthu4mEIpdYKZ3QVTjXl6NCaXqVR0EOhzTiAG/https%3A%2F%2Fahuemer.xx.vu%2Fvolatile%2F2020-05-11-P6C1Wc3u1wU%2F
> [3]
> https://secure-web.cisco.com/1lc47FG678Pn52RvDToQE0dXvwOnbKbGRbN6-Isvy6vMB2s_1yJBYWRZduvax-epmacIYbcnUCmIDLFWsbAlx_fWds6f40LanIVAYPxdce1BHtR1n3vOrRj5HYg2a7X0OUGDmyQo5lbNDPJe4_1ZWQef0LNTjfaSRCzPpj3tZII47tuuxs28-fTaGV4MDSgtO9jaD-f7yC5zLnri6JD3NrMLNk_lXBXHB_Hk3br48XLWLuwVAaggwCCR45N5Hu_758ek0a2pzvPqte89y2l8WKPiWo5YcyZ5zBqkVcMMN8_c2GGaFmeCl8oAT8xZPna0HAe9_wOfiXZhazeqZNXgkLTtp5SIkDA-w89OFkBUEiZ7zDJOBlPKrQImvQ80P_BNvWDFPNOV4FkQzE23fVo7OCcs8cz0F3DWBQ9Vv8LZrlyYfNFgscrOK-BreBPLoDCZPagTbpFJQBCNrgWM8LyVDwQ/https%3A%2F%2Fgithub.com%2Flowobservable%2Fcoax%2Fblob%2Fprotocol%2Fprotocol%2Fprotocol.md
>
> --
> 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
>


--
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: 3270 terminals: CUT vs. DFT

[zMan]

I'd suggest that most terminals were 3278s, so his statement stands.  But
we'll never know.

On Mon, May 11, 2020 at 3:28 PM Seymour J Metz  wrote:

> > Most 3270 terminals seem to be of the (simpler) CUT variant.
>
> I doubt it. Certainly all of these are DFT.
>
> • IBM 3179 G Color Graphic Display Station
> • IBM 3192 G Color Graphics Display Station
> • IBM 3193 Display Station
> • IBM 3194 Display Terminal
> • IBM 3290 Information Panel
> • IBM 3270 Personal Computer.
>
> Does anybody know whether any of the InfoWindow displays are CUT, and, if
> so, which?
>
> I suspect that it will be easier to modify, e.g., x3270 to support the
> 3290 features than to implement DFT without help from IBM, but bitsavers
> does have some 3174 and 3274 CE manuals, and maybe one of them has what you
> need.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Alexander Huemer [alexander.hue...@xx.vu]
> Sent: Monday, May 11, 2020 2:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: 3270 terminals: CUT vs. DFT
>
> Hi
>
> I have a 3290 terminal that I'd like to put to some use. See email
> thread 'Talking to 3270 terminals?' that I started Jan 14.
> Somebody then pointed me to oec[1], which is an awesome project. I have
> built the hardware interface that is required to talk to a 3270 terminal
> on the hardware level. A picture of the interface and a video of the
> terminal can be found at [2].
>
> Now, the friendly person who created oec says that the 3290 is a so
> called DFT (Distributed Function Terminal), in contrast to a CUT
> (Control Unit Terminal). Most 3270 terminals seem to be of the (simpler)
> CUT variant. oec only works with CUT terminals. Extending the
> functionality to enable it to work with DFT terminals isn't trivial.
>
> Does anybody on the list here know of additional documentation besides
> what's mentioned at [3] that could be helpful to implement DFT support?
>
> What would also be very helpful is a protocol trace of any kind of the
> communication between a 3174 and a DFT terminal.
>
> -Alex
>
> [1]
> https://secure-web.cisco.com/1NnRTMD_PTNE56hcPN3Zoil25kvZDUUK_aipLBMH0L1wILqqABd8VqLfLufezSPeE_Fl4x00j7t4NfyMBkNjiG9PZJVFzcisGkVw2zDksozehbGrT1dQrE0Ab77RISHAxIQOxnUnRrTtoTrsSrrPsu0jB_gX0Wu7yY3WQm4OWspA270WOpKiWNPsOuRmstQQpzBMsjKSh2liu3id4kuAg3n_Anb4G2bBwbb4hvDUDYwgDt6oVZYjuuMmpgqXD6BoDKPz8h13B3FNewEGGG-ZmkWrk8Ij2IMQB2BwK-56UDvG1tFuhjaZRmy8w4zpndnP-EtTI3GVvakjoOfX9TfnAX8Jkf44VijzUU9DY-2nBQHJtCnhDUEwfezo4317R__cJdwXO34VGrBQVzqETM7RjUNDyRR0uqgmmjgiazA_-Er6FIi6yH2m1euIXZa34S3xhYqqtFwfDa_ElLFDmsmOI2Q/https%3A%2F%2Fgithub.com%2Flowobservable%2Foec
> [2]
> https://secure-web.cisco.com/1pSKlPn7aH5BVsfyddjr3HyN_XBjHGssIdgXlLr5CxccG7hAYb_O5qPKiIdRoApG1elM2Wd9QHZu8E-Sc0Xs6zVv0qISCsksY98nFPIe4uoRAieXyzi8hgly4lpVu7klwwS9g8wH1b4FfatJ0HsF1a8dfDnI-6l3OxLz3Jy338dAlfK2uq6u0v4C4M0d81GHudLtr_VFDQylLJhpec2y2uLiLbGwjSHUH35bLwEyjNd3ieBfIBxmlVuhlb3l46ibyiWGouVr4Ik0Gv2xmSL7s7rC35o3kYxwRawP7KL4ODxWKDeikbWKj0j2V8_T4TKfXlwLvH-jYtZ5zOnLAg4DNyo6HSLYXAp0Zv235Je698lh_uza4HemJsGDS2-uZNyNE1cuP43_FPksOmUrw6l7Hb2EzSd_Dthu4mEIpdYKZ3QVTjXl6NCaXqVR0EOhzTiAG/https%3A%2F%2Fahuemer.xx.vu%2Fvolatile%2F2020-05-11-P6C1Wc3u1wU%2F
> [3]
> https://secure-web.cisco.com/1lc47FG678Pn52RvDToQE0dXvwOnbKbGRbN6-Isvy6vMB2s_1yJBYWRZduvax-epmacIYbcnUCmIDLFWsbAlx_fWds6f40LanIVAYPxdce1BHtR1n3vOrRj5HYg2a7X0OUGDmyQo5lbNDPJe4_1ZWQef0LNTjfaSRCzPpj3tZII47tuuxs28-fTaGV4MDSgtO9jaD-f7yC5zLnri6JD3NrMLNk_lXBXHB_Hk3br48XLWLuwVAaggwCCR45N5Hu_758ek0a2pzvPqte89y2l8WKPiWo5YcyZ5zBqkVcMMN8_c2GGaFmeCl8oAT8xZPna0HAe9_wOfiXZhazeqZNXgkLTtp5SIkDA-w89OFkBUEiZ7zDJOBlPKrQImvQ80P_BNvWDFPNOV4FkQzE23fVo7OCcs8cz0F3DWBQ9Vv8LZrlyYfNFgscrOK-BreBPLoDCZPagTbpFJQBCNrgWM8LyVDwQ/https%3A%2F%2Fgithub.com%2Flowobservable%2Fcoax%2Fblob%2Fprotocol%2Fprotocol%2Fprotocol.md
>
> --
> 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
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: Colossus, Strangelove, etc. was: Developers say...

[Phil Smith III]

Shmuel wrote:

>I hated it; that level of AI on a 360/75? To say nothing of just reeking of 
>sympathetic magic.

>BTW, the wiki article got the origin of the name wrong; it was P-1 because it 
>ran in partition (remember those) 1. Does anybody know whether Waterloo was 
>actually running MVT on their 75, as seems likely?



Yes, we were. I remember long after the 360 was gone, a virtual machine called 
OSVS2 still running some tiny thing that nobody felt like porting.

 

That book started badly, getting the bloody location of Waterloo wrong for no 
good reason (didn't matter to the story, but they had it on the wrong highway) 
but was at least entertaining.

 

...phsiii


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

Re: 3270 terminals: CUT vs. DFT

[Joe Monk]

When you go look at the code, you see:

  self.type = TerminalType.DFT

self.model = None

self.keyboard = None

which, in essence is not implemented.

Joe

On Mon, May 11, 2020 at 9:01 PM Seymour J Metz  wrote:

> Not if by "straight 3270 data stream" you mean what is documented in 3270
> Information Display System Data Stream Programmer's Reference; that's not
> what flows over the coax. The board and oec translate between the coax data
> stream and the documented 3270 data stream. In addition to that, oec uses
> TN3270 as a transport mechanism for the 3270 data stream, with no
> translation.
>
> I am, however, confused by :oec only works with CUT terminals", since the
> readme refers to both CUT and DFT. Perhaps what they told him is that oec
> doesn't support DSL.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Joe Monk [joemon...@gmail.com]
> Sent: Monday, May 11, 2020 9:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: 3270 terminals: CUT vs. DFT
>
> I understand that.
>
> The interface board he is using translates TN3270 to straight 3270 data
> stream. So, since he wants to connect a 3290, he will need to download
> microcode before he can use the 3290. Thus, he needs to emulate a 3x74
> controller with am ethernet connection (TN3270E) to VTAM/NCP...
>
> "Prerequisites: The IBM 3290 Information Panel attaches to
> the IBM 3274 Control Unit Models 1A, 1C, 1D, 31A, 31C, 31D, 41A,
> 41C, 41D, 51C, and 61C. The 3290 requires the customizing of the
> 3274 and a microcode load from the 3274 to be operational.  A
> 3178, 3278, or 3279 display station with keyboard attached to
> port 0 of the control unit is required for customizing and
> maintenance of the 3274 Control Unit."
>
> Joe
>
> On Mon, May 11, 2020 at 8:34 PM Seymour J Metz  wrote:
>
> > TN3270 encapsulates the 3270 data stream; there's no translation
> involved.
> > Implementing CUT or DFT is a different translation, and that is
> apparently
> > what oec does. Think of TN3270 as an alternative to channel, BSC or SDLC
> > links.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Joe Monk [joemon...@gmail.com]
> > Sent: Monday, May 11, 2020 8:00 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: 3270 terminals: CUT vs. DFT
> >
> > Alex,
> >
> > What you have in that interface is a simple protocol translator ...
> > translating bi-directional TN3270 to 3270 Data Stream. That is great to
> > drive a 3270 dumb terminal.
> >
> > The first thing you need is to emulate a real control unit ... like a
> 3174
> > or 3274.
> >
> > If you read the product letter:
> > https://www-01.ibm.com/common/ssi/rep_ca/3/897/ENUS183-033/index.html
> >
> > "The 3290 utilizes microcode loaded from the IBM 3274 Control Unit to
> > provide screen-management facilities
> > for improved end-user ease of use."
> >
> > So, you need some microcode for the 3290, then you need to be able to
> load
> > it to the 3290 on request from your OEC. Once you have that working, then
> > the rest will kinda fall into place with the DFT functionality on the
> OEC.
> >
> > Joe
> >
> > On Mon, May 11, 2020 at 1:18 PM Alexander Huemer  >
> > wrote:
> >
> > > Hi
> > >
> > > I have a 3290 terminal that I'd like to put to some use. See email
> > > thread 'Talking to 3270 terminals?' that I started Jan 14.
> > > Somebody then pointed me to oec[1], which is an awesome project. I have
> > > built the hardware interface that is required to talk to a 3270
> terminal
> > > on the hardware level. A picture of the interface and a video of the
> > > terminal can be found at [2].
> > >
> > > Now, the friendly person who created oec says that the 3290 is a so
> > > called DFT (Distributed Function Terminal), in contrast to a CUT
> > > (Control Unit Terminal). Most 3270 terminals seem to be of the
> (simpler)
> > > CUT variant. oec only works with CUT terminals. Extending the
> > > functionality to enable it to work with DFT terminals isn't trivial.
> > >
> > > Does anybody on the list here know of additional documentation besides
> > > what's mentioned at [3] that could be helpful to implement DFT support?
> > >
> > > What would also be very helpful is a protocol trace of any kind of the
> > > communication between a 3174 and a DFT terminal.
> > >
> > > -Alex
> > >
> > > [1]
> >
>