Discussion:
[hercules-os380] socket device
kerravon86@yahoo.com.au [hercules-os380]
2018-11-01 18:43:42 UTC
Permalink
Rather than using Jason Winter's x'75'
opcode, or my SVC 120 API call, would
it make sense to have an artificial
TCP/IP device that has CCWs that call
the appropriate TCP/IP functions?

Although I think applications will still
require the EZASOKET API which needs
to be implemented as CCWs, and that
may as well be hidden in the SVC 120
API.

BFN. Paul.
Gerhard Postpischil gerhardp@charter.net [hercules-os380]
2018-11-02 02:39:32 UTC
Permalink
Post by ***@yahoo.com.au [hercules-os380]
Rather than using Jason Winter's x'75'
opcode, or my SVC 120 API call, would
it make sense to have an artificial
TCP/IP device that has CCWs that call
the appropriate TCP/IP functions?
Although I think applications will still
require the EZASOKET API which needs
to be implemented as CCWs, and that
may as well be hidden in the SVC 120
API.
Adding a device type to MVS is rather messy. The contents of CCW chains
is checked by EXCP and EXCPVR SVCs (page fixing, etc.); authorized tasks
may use STARTIO and handle page fixing themselves. But that still leaves
the problems of error handling, LOGREC recording, and attention
handling. The last time I tried anything like that was to support a
2495 six months before IBM added system support, and it was close enough
to a tape drive that I could get away with minor changes.

Gerhard Postpischil
Bradford, VT


---
This email has been checked for viruses by AVG.
https://www.avg.com
kerravon86@yahoo.com.au [hercules-os380]
2018-11-02 10:29:25 UTC
Permalink
What you need is the TCPIP stack on MVS to
drive that comm port via a packet driver.
The whole point is to avoid having to write
a TCP/IP stack and just access the host
TCP/IP stack like Jason already does.

But instead of a fake instruction have a
fake device.

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-os380]
2018-11-02 11:55:05 UTC
Permalink
"But instead of a fake instruction have a
fake device."

On MVS, its not that simple. As you know, you have to SYSGEN for I/O, which
means you have to modify all the SYSGEN macros. Its a lot of work for
little gain.

A fake instruction is novice play compared to a fake device.

Joe
Post by ***@yahoo.com.au [hercules-os380]
What you need is the TCPIP stack on MVS to
drive that comm port via a packet driver.
The whole point is to avoid having to write
a TCP/IP stack and just access the host
TCP/IP stack like Jason already does.
But instead of a fake instruction have a
fake device.
BFN. Paul.
kerravon86@yahoo.com.au [hercules-os380]
2018-11-02 12:32:04 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-os380]
Post by ***@yahoo.com.au [hercules-os380]
But instead of a fake instruction have a
fake device.
On MVS, its not that simple. As you know, you
have to SYSGEN for I/O, which means you
have to modify all the SYSGEN macros. Its a
lot of work for little gain.
It should be possible to just issue CCWs
without MVS knowing about the device at all.

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-os380]
2018-11-02 16:15:32 UTC
Permalink
Hmmm, so what do you think is going to happen when MVS initializes the
channel at IPL that your device will be attached to? How will you issue
CCWs to the device without MVS knowing about it? Remember, all interrupts
are handled by MVS. So, when you issue a CCW and the channel issues an
interrupt, how will that interrupt be handled?

Joe
Post by ***@yahoo.com.au [hercules-os380]
Post by Joe Monk ***@gmail.com [hercules-os380]
Post by ***@yahoo.com.au [hercules-os380]
But instead of a fake instruction have a
fake device.
On MVS, its not that simple. As you know, you
have to SYSGEN for I/O, which means you
have to modify all the SYSGEN macros. Its a
lot of work for little gain.
It should be possible to just issue CCWs
without MVS knowing about the device at all.
BFN. Paul.
kerravon86@yahoo.com.au [hercules-os380]
2018-11-02 16:35:09 UTC
Permalink
Ok, thanks, I see the issue now. I was just
thinking about PDOS issuing CCWs fine,
but yes, I have control over the interrupts
there.

BFN. Paul.



---In hercules-***@yahoogroups.com, <***@gmail.com> wrote :

Hmmm, so what do you think is going to happen when MVS initializes the channel at IPL that your device will be attached to? How will you issue CCWs to the device without MVS knowing about it? Remember, all interrupts are handled by MVS. So, when you issue a CCW and the channel issues an interrupt, how will that interrupt be handled?


Joe
Post by Joe Monk ***@gmail.com [hercules-os380]
Post by ***@yahoo.com.au [hercules-os380]
But instead of a fake instruction have a
fake device.
On MVS, its not that simple. As you know, you
have to SYSGEN for I/O, which means you
have to modify all the SYSGEN macros. Its a
lot of work for little gain.
It should be possible to just issue CCWs
without MVS knowing about the device at all.

BFN. Paul.
'Dave Wade' dave.g4ugm@gmail.com [hercules-os380]
2018-11-02 17:04:25 UTC
Permalink
Joe,

In a past life, when we wanted to talk X.25 to VM we defined the link as a pair of 3270 devices, one for send and one for receive. The problem with a device is that if you want multiple programs to have access to TCPIP then I believe that you need a sub-system to manage the device, so your application talks to the subsystem, which then talks to the device.



Personally I would look at catching the VMCF calls (DIAG 68) or IUCV which is a pseudo instruction




Dave



From: hercules-***@yahoogroups.com <hercules-***@yahoogroups.com>
Sent: 02 November 2018 16:16
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-os380] socket device








Hmmm, so what do you think is going to happen when MVS initializes the channel at IPL that your device will be attached to? How will you issue CCWs to the device without MVS knowing about it? Remember, all interrupts are handled by MVS. So, when you issue a CCW and the channel issues an interrupt, how will that interrupt be handled?



Joe
Post by Joe Monk ***@gmail.com [hercules-os380]
Post by ***@yahoo.com.au [hercules-os380]
But instead of a fake instruction have a
fake device.
On MVS, its not that simple. As you know, you
have to SYSGEN for I/O, which means you
have to modify all the SYSGEN macros. Its a
lot of work for little gain.
It should be possible to just issue CCWs
without MVS knowing about the device at all.

BFN. Paul.
Rahim Azizarab rahimazizarab@yahoo.com [hercules-os380]
2018-11-02 19:49:02 UTC
Permalink
I have been thinking of a special tape device driver that we modify a bit.  When we write to it we convert to ASCII and when we read from it we convert ebcdic. Also when something is written to this tape we issue some system interrupt to say hey come and process this data.  This is just about all we need to do on the MVS side.  The rest of processing this data would be handled from Hercules side just like a socket data.  There would be a need to monitor an interrupt both on the MVS and Hercules sides when a read or write to this device is performed.


regards;
Rahim
Joe Monk joemonk64@gmail.com [hercules-os380]
2018-11-02 23:08:42 UTC
Permalink
You guys are making this way too hard.

All you need is a comm line defined in VTAM. That connects directly to the
underlying PC ... there are plenty of shims that take I/o from a virtual
com port and turn it into tcpip.

So, you use Standard VTAM ACB calls to open read write close.

Joe
Post by Rahim Azizarab ***@yahoo.com [hercules-os380]
I have been thinking of a special tape device driver that we modify a
bit. When we write to it we convert to ASCII and when we read from it we
convert ebcdic. Also when something is written to this tape we issue some
system interrupt to say hey come and process this data. This is just
about all we need to do on the MVS side. The rest of processing this data
would be handled from Hercules side just like a socket data. There would
be a need to monitor an interrupt both on the MVS and Hercules sides when a
read or write to this device is performed.
regards;
Rahim
Rahim Azizarab rahimazizarab@yahoo.com [hercules-os380]
2018-11-03 14:03:27 UTC
Permalink
Joe;
you seem to have a bright idea.  It would be nice if you would elucidate us with some more details maybe with a pointer to an example.  Do you happen to know if there is any device driver for 3088 in MVS38?  My guess is there is not. 


regards;
Rahim
Joe Monk joemonk64@gmail.com [hercules-os380]
2018-11-03 15:17:51 UTC
Permalink
Well we do have a 3705, right? So if you know how to work with a 3705, then
you can get what you want...

Joe
Joe;
you seem to have a bright idea. It would be nice if you would elucidate
us with some more details maybe with a pointer to an example. Do you
happen to know if there is any device driver for 3088 in MVS38? My guess
is there is not.
regards;
Rahim
pricgren pricgren@yahoo.com [hercules-os380]
2018-11-04 05:45:50 UTC
Permalink
Post by Rahim Azizarab ***@yahoo.com [hercules-os380]
Do you happen to know if there is any device driver for 3088 in MVS38?
How does Shelby's DDT work?
It uses a couple of 3088 I/O devices defined in Herc as TCP/IP ports, I
believe.

And I'll mention that when IBM first connected the 3720 (I do not mean
3270) comms controller to support TCP/IP for MVS (and VM may well have
had TCPIP first), it was defined in HCD as 2 3088 CTCA devices (even-odd
consecutive addresses so specifying 1 address specified the address
pair), one for read and one for write.  You could tell which one was for
read because it always had an I/O active, but I forget which was which.

The I/O devices were allocated to the TCPIP address space, of course,
which managed all I/O between host and controller.

Cheers,
Greg
Tony Harminc tharminc@gmail.com [hercules-os380]
2018-11-05 22:03:26 UTC
Permalink
Joe;
you seem to have a bright idea. It would be nice if you would elucidate
us with some more details maybe with a pointer to an example. Do you
happen to know if there is any device driver for 3088 in MVS38? My guess
is there is not.
You would be right, because MVS does not have the notion of "device driver".

Tony H.
kerravon86@yahoo.com.au [hercules-os380]
2018-11-06 00:42:40 UTC
Permalink
Post by Tony Harminc ***@gmail.com [hercules-os380]
Post by Rahim Azizarab ***@yahoo.com [hercules-os380]
Do you happen to know if there is any device
driver for 3088 in MVS38? My guess is there is not.
You would be right, because MVS does not
have the notion of "device driver".
What is the reason for that difference
between mainframe and PC?

Thanks. Paul.
Mike Schwab Mike.A.Schwab@gmail.com [hercules-os380]
2018-11-06 02:21:08 UTC
Permalink
CCWs and I/O processors for the mainframe.
Post by ***@yahoo.com.au [hercules-os380]
Post by Tony Harminc ***@gmail.com [hercules-os380]
Post by Rahim Azizarab ***@yahoo.com [hercules-os380]
Do you happen to know if there is any device
driver for 3088 in MVS38? My guess is there is not.
You would be right, because MVS does not
have the notion of "device driver".
What is the reason for that difference
between mainframe and PC?
Thanks. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
'Dave Wade' dave.g4ugm@gmail.com [hercules-os380]
2018-11-06 08:18:38 UTC
Permalink
-----Original Message-----
Sent: 06 November 2018 00:43
Subject: Re: [hercules-os380] Re: socket device
Post by Tony Harminc ***@gmail.com [hercules-os380]
Post by Rahim Azizarab ***@yahoo.com [hercules-os380]
Do you happen to know if there is any device driver for 3088 in
MVS38? My guess is there is not.
You would be right, because MVS does not have the notion of "device driver".
What is the reason for that difference
between mainframe and PC?
History? Terminology? Operating Systems Structure?
Thanks. Paul.
------------------------------------
------------------------------------
Tony Harminc tharminc@gmail.com [hercules-os380]
2018-11-07 21:44:51 UTC
Permalink
Post by ***@yahoo.com.au [hercules-os380]
Post by Tony Harminc ***@gmail.com [hercules-os380]
Post by Rahim Azizarab ***@yahoo.com [hercules-os380]
Do you happen to know if there is any device
driver for 3088 in MVS38? My guess is there is not.
You would be right, because MVS does not
have the notion of "device driver".
What is the reason for that difference
between mainframe and PC?
I think at the time the PC moved into the mainstream (i.e. when clones of
the IBM originals started to appear, and non-IBM cards came on the market),
it became apparent that a standard interface between peripheral devices and
OS APIs was needed. That's what device drivers do - provide a standard API
on one side and know how to deal with the device specifics on the other.
(There may well be intermediate APIs that application programs typically
call, but those don't map directly to the device ones.)

This is a brilliant concept, and one of the few things where the PC has
outdone S/360 and its descendants.

Of course there were (and still are to a smaller extent) third party
hardware devices that connect to IBM mainframes, but in the vast majority
of cases they are clones at the interface, e.g. a Telex or Memorex or STK
disk drive or printer or 3270 or even FEP aimed to behave exactly as the
IBM device. Only a very few devices required any sort of low-level code to
function; those typically came with an I/O appendage to handle interrupts.
Channel-attached Calcomp and Gould plotters come to mind.

Tony H.
kerravon86@yahoo.com.au [hercules-os380]
2018-11-07 22:24:04 UTC
Permalink
Post by Tony Harminc ***@gmail.com [hercules-os380]
Post by ***@yahoo.com.au [hercules-os380]
Post by Tony Harminc ***@gmail.com [hercules-os380]
Post by Rahim Azizarab ***@yahoo.com [hercules-os380]
Do you happen to know if there is any device
driver for 3088 in MVS38? My guess is there is not.
You would be right, because MVS does not
have the notion of "device driver".
What is the reason for that difference
between mainframe and PC?
This is a brilliant concept, and one of the few
things where the PC has outdone S/360 and
its descendants.
Can PDOS/3x0 support device drivers? Including
if it were running on real hardware.

Thanks. Paul.
Tony Harminc tharminc@gmail.com [hercules-os380]
2018-11-08 18:17:21 UTC
Permalink
Post by ***@yahoo.com.au [hercules-os380]
Post by Tony Harminc ***@gmail.com [hercules-os380]
This is a brilliant concept, and one of the few
things where the PC has outdone S/360 and
its descendants.
Can PDOS/3x0 support device drivers? Including
if it were running on real hardware.
I imagine so. I mean, you can invent/design your own scheme for how they
would work, and then publish your specs so that hardware vendors can write
PDOS drivers and make them available with their hardware.

Realistically, you presumably want to use existing drivers written for
Windows or Linux or whatever.

I don't know anything about the details of this stuff (I've never written
either a device driver or the OS code to call it), but the place to look
would be Linux. I'm pretty sure it's possible to install *some* drivers for
Windows into *some* Linux systems. Linux distributions don't generally
include such drivers, because they're OCO, but for people who have some
weird or abandoned (or alternatively, very new) device, it may be the only
way to go. You would presumably have to provide an environment such that
the driver things it's executing in the environment it was written for.

Linux (and probably BSD and such) do have some drivers in source form for
common devices, so that - combined with source code for the OS itself -
would give you a good idea of how the whole scheme works.

IIRC way back when some MS/DOS LAN card drivers (NDIS?) could be used on
OS/2, so that may be another place to look, though there won't be source
code.

Tony H.
kerravon86@yahoo.com.au [hercules-os380]
2018-11-09 02:10:32 UTC
Permalink
Post by Tony Harminc ***@gmail.com [hercules-os380]
Post by ***@yahoo.com.au [hercules-os380]
Post by Tony Harminc ***@gmail.com [hercules-os380]
I think at the time the PC moved into the mainstream
(i.e. when clones of the IBM originals started to appear,
and non-IBM cards came on the market), it became
apparent that a standard interface between peripheral
devices and OS APIs was needed. That's what device
drivers do - provide a standard API on one side and
know how to deal with the device specifics on the other.
(There may well be intermediate APIs that application
programs typically call, but those don't map directly to
the device ones.)
Can PDOS/3x0 support device drivers? Including
if it were running on real hardware.
I imagine so. I mean, you can invent/design your own
scheme for how they would work, and then publish
your specs so that hardware vendors can write PDOS
drivers and make them available with their hardware.
Can we design something from first principles?

Would a good example be adding a joystick
hardware for PDOS/390 running on real
hardware?

The joystick is meant to be used on the
console (not sure what to call it) that you
do an IPL from.

I would suggest that the device driver should
install itself so that it intercepts the SVC 120
interrupt. Applications could then write code
like this:

typedef struct {
unsigned short xpos;
unsigned short ypos;
unsigned char buttons;
} JOYINF;

int GetJoy(JOYINF *joyinf)
{
int ret;

ret = svc120(0xffffffe5, joyinf);
return (ret);
}

So PDOS/390 needs to provide an API for
the device driver to call that will allow a
hook to be placed into an SVC so that it
gets first control to see if this is an API
call for a controlled device.

Maybe this is not a good example as the
device doesn't cause an interrupt. We
need a way for device drivers to hook
into the interrupt mechanism too.
ie the code behind FLCINPSW
Currently that code in PDOS/3x0 is
extremely crude, precisely because it is
yet to be properly designed. Maybe now
is the time to design it properly.

BFN. Paul.
Mike Schwab Mike.A.Schwab@gmail.com [hercules-os380]
2018-11-07 22:51:37 UTC
Permalink
Well, the I/O controllers just worried about getting the data to and from
the Device Controller. That is where the wiring and microcode to handle
the device are stored.
Post by Tony Harminc ***@gmail.com [hercules-os380]
Post by ***@yahoo.com.au [hercules-os380]
Post by Tony Harminc ***@gmail.com [hercules-os380]
Post by Rahim Azizarab ***@yahoo.com [hercules-os380]
Do you happen to know if there is any device
driver for 3088 in MVS38? My guess is there is not.
You would be right, because MVS does not
have the notion of "device driver".
What is the reason for that difference
between mainframe and PC?
I think at the time the PC moved into the mainstream (i.e. when clones of
the IBM originals started to appear, and non-IBM cards came on the market),
it became apparent that a standard interface between peripheral devices and
OS APIs was needed. That's what device drivers do - provide a standard API
on one side and know how to deal with the device specifics on the other.
(There may well be intermediate APIs that application programs typically
call, but those don't map directly to the device ones.)
This is a brilliant concept, and one of the few things where the PC has
outdone S/360 and its descendants.
Of course there were (and still are to a smaller extent) third party
hardware devices that connect to IBM mainframes, but in the vast majority
of cases they are clones at the interface, e.g. a Telex or Memorex or STK
disk drive or printer or 3270 or even FEP aimed to behave exactly as the
IBM device. Only a very few devices required any sort of low-level code to
function; those typically came with an I/O appendage to handle interrupts..
Channel-attached Calcomp and Gould plotters come to mind.
Tony H.
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
ikj1234i@yahoo.com [hercules-os380]
2018-11-09 19:25:26 UTC
Permalink
---In hercules-***@yahoogroups.com, <***@...> wrote :


What is the reason for that difference
between mainframe and PC?
Post by Tony Harminc ***@gmail.com [hercules-os380]
This is a brilliant concept, and one of the few things where the PC
has outdone S/360 and its descendants.
Not the first time I've seen this from Tony - ascribing to the PC

and obscuring the actual historical origins of something that
actually came down to us via Ken Thompson or Dennis Ritchie.


In this case the term "device driver" goes back at least as far as the

1978 Bell System Technical Journal issue on the Unix Time-Sharing
System.


Not saying it doesn't go back further than that, just that it's sufficient to

document an instance that predates the PC.... The same issue contains
articles that should make clear many areas where S/360 and its
descendants were brilliantly outdone (including some interesting
commentary on Brooks and his Mythical Man Month).



In case all this isn't clear, take a look at any URL, including (most
likely) the one at the top of the page you're viewing this message in.
In the URL, note which way the directory separator characters point
(i.e. it's http:// - not http:\\)


Max
Vince Coen vbcoen@gmail.com [hercules-os380]
2018-11-09 23:21:04 UTC
Permalink
Totally missed the point of 'device drivers' !

When the 360 came out the only devices peripherals was from IBM so
needless to say the code to talk to the concentrators or controllers was
included at sysgen subject to what was installed.

With the arrival of the 370 third party peripherals came on the the
market to:

1 Increase the range
2 Reduce TCO
3. Improve the product type in through put and/or reliability.

How ever it did mean the engineer requirements went up as you had one
(or more) for the IBM supplied system and one or more for the 3rd party kit.

Of course more space to house the extra manuals so any site had a full
reference for the engineers.
Many of which were in ring binders (handy for the update pages) that IBM
charged extra for those site that did not negotiate a tight contract.

The 3rd party suppliers have thinned down some what over the years but
the support requirements stays.

The secondary suppliers have to supply the code for sysgen or its later
sisters when a new version of the system is built which does tend to
keep the sysprogs amused.

So basically there does exist a form of device drivers but it is not the
same.
If you really want to look at the code for specific peripherals take a
look at the input libraries to sysgen.
Some site do the the sources of these again depending on the purchase
contracts but there again any one with brains or more importantly been
sting once will make sure of this.

Here ends the lesson thanks to almost 60 years experience..

Vince.
Post by ***@yahoo.com.au [hercules-os380]
What is the reason for that difference
between mainframe and PC?
Post by Tony Harminc ***@gmail.com [hercules-os380]
This is a brilliant concept, and one of the few things where the PC
has outdone S/360 and its descendants.
Not the first time I've seen this from Tony - ascribing to the PC
and obscuring the actual historical origins of something that
actually came down to us via Ken Thompson or Dennis Ritchie.
In this case the term "device driver" goes back at least as far as the
1978 Bell System Technical Journal issue on the Unix Time-Sharing
System.
Not saying it doesn't go back further than that, just that it's sufficient to
document an instance that predates the PC....  The same issue contains
articles that should make clear many areas where S/360 and its
descendants were brilliantly outdone (including some interesting
commentary on Brooks and his Mythical Man Month).
In case all this isn't clear, take a look at any URL, including (most
likely) the one at the top of the page you're viewing this message in.
In the URL, note which way the directory separator characters point
(i.e. it's http:// - not http:\\)
Rahim Azizarab rahimazizarab@yahoo.com [hercules-os380]
2018-11-05 14:54:53 UTC
Permalink
Thanks Greg.  It was a good lead.  I will dig into it in more details.
regards;

Rahim
Loading...