[hercules-os380] reimplementing unix

[[e-mail] [hercules-os380]]

I have seen a saying "those who do not
understand Unix are doomed to
reimplement it badly".

Specifically what about either PDOS/386
(which is similar to MSDOS), or
PDOS/370 (which is similar to both
MSDOS and MVS) is going to be
currently or permanently implemented
badly because I don't understand Unix
properly?

Is it because there's no fork() and I
don't intend to implement fork(), and
only implement exec() and ATTACH
instead?

Or is it because the file system doesn't
have ugw permissions, and instead
has either MSDOS or MVS file
attributes?

Or is it everything? ie any small
deviation from the latest standard
of Posix makes an operating system
crap, because the latest standard of
Posix, and no other, is perfect?

Or is it the first version of Posix that
was perfect?

Or was it some version of Kernighan's
personal system that was divine?

I remember someone older than me telling
me that Unix was radical because it introduced
the concept that a file was just a
sequence of bytes. I'm not sure what
concept I have had previously or now,
but I do indeed visualize everything
as a sequence of bytes from either a
text file or a binary file, regardless of
whether I am using PDPCLIB on MVS
or MSDOS.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

If that quote were applied to MVS, it would say:

"those who do not understand MVS and the mainframe are doomed to
reimplement it badly"

Joe

Post by ***@yahoo.com.au [hercules-os380]
I have seen a saying "those who do not
understand Unix are doomed to
reimplement it badly".
Specifically what about either PDOS/386
(which is similar to MSDOS), or
PDOS/370 (which is similar to both
MSDOS and MVS) is going to be
currently or permanently implemented
badly because I don't understand Unix
properly?
Is it because there's no fork() and I
don't intend to implement fork(), and
only implement exec() and ATTACH
instead?
Or is it because the file system doesn't
have ugw permissions, and instead
has either MSDOS or MVS file
attributes?
Or is it everything? ie any small
deviation from the latest standard
of Posix makes an operating system
crap, because the latest standard of
Posix, and no other, is perfect?
Or is it the first version of Posix that
was perfect?
Or was it some version of Kernighan's
personal system that was divine?
I remember someone older than me telling
me that Unix was radical because it introduced
the concept that a file was just a
sequence of bytes. I'm not sure what
concept I have had previously or now,
but I do indeed visualize everything
as a sequence of bytes from either a
text file or a binary file, regardless of
whether I am using PDPCLIB on MVS
or MSDOS.
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]
"those who do not understand MVS and
the mainframe are doomed to
reimplement it badly"

Do you consider Unix to be a poorly-implemented
version of MVS?


I found the exact quote here:

https://groups.yahoo.com/neo/groups/hercules-390/conversations/messages/65453

"Those who don't understand UNIX are condemned to reinvent it, poorly." Henry Spencer


Note that although I used Unix for many
years, I didn't really do much/any
"system level" coding. I did much more
system level coding on MVS. So I would
probably be classified as one of the
above people who "don't understand
Unix". And in fact, what learning I am
doing is in part coming from adding
Unix-like features to PDOS.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

Unix and MVS have no relationship.

Unix is an offshoot of Multics, while OS/360 was written from scratch.

Multics was written in PL/1...

OS/360 was written in assembler.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
"those who do not understand MVS and
the mainframe are doomed to
reimplement it badly"

Do you consider Unix to be a poorly-implemented
version of MVS?
https://groups.yahoo.com/neo/groups/hercules-390/
conversations/messages/65453
"Those who don't understand UNIX are condemned to reinvent it, poorly." Henry Spencer
Note that although I used Unix for many
years, I didn't really do much/any
"system level" coding. I did much more
system level coding on MVS. So I would
probably be classified as one of the
above people who "don't understand
Unix". And in fact, what learning I am
doing is in part coming from adding
Unix-like features to PDOS.
BFN. Paul.

[[e-mail] [hercules-os380]]

I'd also suggest (Paul) that you need to look at later standards than
C90 since they might resolve some of the issues you've been struggling
with. After all, in the late 80s IBM really had no reason to be involved
in the standardisation process, or if they had a need it was in the
context of AIX rather than MVS.

C90? As far as I know, IBM was involved
in C90 to make sure that MVS was
covered, and indeed, it is covered, very
very well. I would like you to point me to
a deficiency that exists on MVS's support
of C90 that doesn't exist on Windows.

I can remember seeing a comment by
someone that during the standardization
process, Unix people were complaining
"why is it so complicated" and IBM had
to patiently explain records to them.

As far as I know, MVS was one of the
first manufacturers to provide a compliant
C89 compiler.

If you're instead talking about Posix,
then although I'm not familiar with the
standardization of that, I believe MVS
was one of the first manufacturers to
be Posix-compliant too.

I'm not sure what more they can do
as far as being "relevant".

BFN. Paul.

[[e-mail] [hercules-os380]]

Thanks for the corrections. But IIRC you've said in the past that you
weren't looking at later versions of the C standard until you've got C90
fully-implemented, I'd suggest that you do need to look at them since
they might throw light on things you're having a problem with.

Can you tell me what things "I am having
a problem with", because I have no idea
what you are referring to.

BFN. Paul.

[[e-mail] [hercules-os380]]

the standard C libraries. And I'd highlight the particular culprits of
systems which had nominal support for fork(), but didn't implement the
expected memory model.

So perhaps the inefficient implementation
of fork(), ie failing to reuse the same
executable code and instead forcing a
new copy of the executable to be loaded,
makes any application using fork() to be
incredibly inefficient when not using
Unix.

Thus rendering an entire class of
application, including standard gcc,
that contains a fork(), to be inefficient
on non-Unix platforms?

I can (possibly) see that, but I would
solve that problem by eliminating the
use of fork(), as something like gcc
has no need to be introducing a
dependency on such a concept. All
gcc really requires is something like
MSDOS exec().

What /is/ important is things like
the behaviour of file handles, their
behaviour over fork/exec or equivalent,
and so on.

Ok, but both MSDOS and PDOS/386
have the concept of OS-maintained
file handles and doing an MSDOS
exec() preserves file handles to the
same extent as Unix, as far as I
know.

I guess here I can see a difference
with MVS, and the struggle to preserve
SYSIN/SYSPRINT over a system()
call. But even that problem doesn't
exist if you simply run under TSO.

You could argue that running under
TSO doesn't allow file redirection
though, making it inferior to Unix.
But it may actually be possible to
introduce file redirection in PDOS/370,
without the existing MVS/TSO API
needing to be changed at all.

And if we are then left with only
z/OS (possibly) not supporting file
redirection, if that hole is plugged
does Unix lose its status as the
best an operating system can
actually be (that's how I read the
quote, anyway).

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I can (possibly) see that, but I would
solve that problem by eliminating the
use of fork(), as something like gcc
has no need to be introducing a
dependency on such a concept.

fast-forking seems to me to be a
self-fulfilling prophecy.

Wow, Unix has introduced a fork()
concept. Ok, cool, let's use it a lot
in all our programs.

Now those programs are much
slower on unrelated platforms that
have no inherent concept of fork(),
and it's amazing that they managed
to implement fork() at all.

Woo hoo, Unix is so much faster at
running programs like GCC. Unix
is tops! Nothing else is as efficient.

When in fact an application like GCC
should be purely dependent on how
many instructions are required to
optimize a piece of code, not how
fast an arbitrary operating system
can implement a ridiculous call
for an *application program* to be
making, ie fork().

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

What /is/ important is things like
the behaviour of file handles, their
behaviour over fork/exec or equivalent,
and so on.

I guess here I can see a difference
with MVS, and the struggle to preserve
SYSIN/SYSPRINT over a system()
call.

Also, even if Unix is so great with its
file handles, is it really appropriate to
be directly using file handles instead
of using whatever your language
standard tells you to use?

It's not like Unix programmers are
even mainly writing in assembler so
that they don't have a language
environment to shield them from
this low-level detail.

And even if you have a Unix C
program calling a Unix Pascal
program, is it really appropriate
to be passing (or hardcoding)
an already-open file handle to
use? Other than 0/1/2 which
they are allowed to know
about if required.

Does this have any justification
for an *application program*?
Let's start with genuine business
applications.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]

What /is/ important is things like
the behaviour of file handles, their
behaviour over fork/exec or equivalent,
and so on.

I guess here I can see a difference
with MVS, and the struggle to preserve
SYSIN/SYSPRINT over a system()
call.

Also, even if Unix is so great with its
file handles, is it really appropriate to
be directly using file handles instead
of using whatever your language
standard tells you to use?

ie if the answer is "no, it's not
appropriate", then what difference
does it make if the OS maintains
files with file handle numbers
instead of DCB addresses?

At what point does Unix become
the bees knees?

Note that while writing this message,
at the start I needed to wait something
like 10 seconds between keypresses.
ie we still don't have computers fast
enough to keep up with my typing
speed, under certain circumstances.
In 2017. And it's not like I'm using
some obscure operating system and
a computer from an obscure
manufacturer with an obscure CPU.

I'm literally using Windows, Dell and
Intel. Even though I'm normally a fan
of competitors.

This problem wouldn't have happened
on PDOS/370.

So at this point can I say that PDOS/370
is the bees knees of operating systems,
beating the pants off things like Windows
that sometimes take 10 seconds to
respond to a keystroke? Even when
this is my only foreground window, in
fullscreen and there is more than one
core available.

An unrelated comment - I have seen
comments like "Windows is not meant
to be a real-time operating system".
Is this what makes Unix allegedly
perfect, dooming all other attempts
at writing a better operating system?

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
Thus rendering an entire class of
application, including standard gcc,
that contains a fork(), to be inefficient
on non-Unix platforms?

But the fact remains that that's what the designers of UNIX did, so if
you're talking about making sure that something's unix-compatible that's
what you've got to do as well.

No, I'm not talking about making something
unix-compatible, I'm trying to understand
why I would be "condemned to reimplement
Unix badly" if I decided to *change* Unix. In
case I was missing something.

/Please/ don't expect me to defend unix's memory model, except for a
broad observation that it's turned out to be fairly easily implemented
on a very wide range of computers even if their hardware provided better
alternatives. But the fact remains that we're stuck with it.

I don't consider that we are stuck with it,
any more than we are stuck with MVS
and need to copy everything that MVS
does, not change one iota.

The first thing I would do is deprecate
fork() and exec() from Posix and replace
them with MSDOS-style exec or spawn
or whatever the correct terminology is
to implement system() on MSDOS.

The same way that C11 deprecated
C90 gets().

Applications have no business whatsoever
calling either fork() or gets(), each for different
reasons.

Post by ***@yahoo.com.au [hercules-os380]
Also, even if Unix is so great with its
file handles, is it really appropriate to
be directly using file handles instead
of using whatever your language
standard tells you to use?

Again, not relevant. You're asking about making something
unix-compatible, not making it into a generic C platform.

No, that is not correct. I am just leery
about deviating from Unix when I have
been explicitly told that those who
deviate from Unix will always end up
with something worse (like Chavez
insisted he was smarter than the
entire western world - I don't want
to end up like Chavez), and now that
I have some knowledge of Unix, MVS
and MSDOS I'm having difficulty
isolating specifically what it is that
supposedly makes Unix the pinnacle
of operating system design, so that
I know what I can and can't change
in PDOS or MVS/380 or anything
else.

ie if someone told me "listen, those
ugo permissions are absolutely
crucial, it is impossible to deviate
from them, for xyz reason", then
maybe I would be spending a lot
of time thinking of implementing zfs
or whatever for PDOS/370, because
sorry, MVS & MSDOS-style file attributes
are simply unworkable. Or keep the
current VTOC, but have an additional
file called PERMISS to store those
absolutely crucial permissions.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

But the fact remains that that's what the designers of UNIX did, so if
you're talking about making sure that something's unix-compatible that's
what you've got to do as well.

No, I'm not talking about making something
unix-compatible,

Apologies for the misleading subject line.

As the fat guy on "This morning with
Richard not Judy" would say "I didn't
think it through!".

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
No, that is not correct. I am just leery
about deviating from Unix when I have
been explicitly told that those who
deviate from Unix will always end up
with something worse (like Chavez
insisted he was smarter than the
entire western world - I don't want
to end up like Chavez),

Perhaps the correct technical solution
to this problem is to simply not pay too
much attention to what idiots on the
internet say - even if they say it
ex-cathedra.

BFN. Paul.

[Tony Harminc [e-mail] [hercules-os380]]

On 15 September 2017 at 05:39, Mark Morgan Lloyd

If you really don't like the unix design philosophy then why are you
using it as a groundplan at all? You might be better looking at a
Windows derivative and starting off with something like
http://www.jbox.dk/sanos/index.htm

Or, in light of the communications-oriented discussion above, Plan 9
https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs . Unixy, but
network oriented. Open source under licensing conditions that are
probably acceptable even to Paul, and weird cultural references
galore. I particularly like the beautifully dense "Plan 9 from User
Space", though it's mostly just a bunch of Unix apps.

Tony H.

[Liam Proven [e-mail] [hercules-os380]]

Post by Tony Harminc ***@gmail.com [hercules-os380]
On 15 September 2017 at 05:39, Mark Morgan Lloyd

If you really don't like the unix design philosophy then why are you
using it as a groundplan at all? You might be better looking at a
Windows derivative and starting off with something like
http://www.jbox.dk/sanos/index.htm

Or, in light of the communications-oriented discussion above, Plan 9
https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs . Unixy, but
network oriented. Open source under licensing conditions that are
probably acceptable even to Paul, and weird cultural references
galore. I particularly like the beautifully dense "Plan 9 from User
Space", though it's mostly just a bunch of Unix apps.

Ha! I was thinking of suggesting that.

It's deeply multi-machine and network-aware, too.

Paul would learn almost infinitely more by porting Plan 9 to Hercules
than by any amount of retrofitting features to obsolete IBM OSes --
but I don't think it would interest him, sadly.

And of course there is also a successor to Plan 9 itself: Inferno.

Plan 9 is essentially Unix 2.0 -- it restructures the code and OS,
brings networking deep into the kernel, and dictates a strict coding
style, rectifying many of the things Unix's creators later
reconsidered.

Inferno is Plan 9, but made processor-independent. It has a virtual
machine deeply embedded into the kernel, meaning that the same OS
binaries can run on any supported CPU -- all programs become
CPU-independent. The VM is called Dis, and targeting it is a type-safe
language, Limbo, that replaces C.

This is the same idea as was implemented in Tao's Intent OS, the
successor to the earlier Taos. However, that was closed-source and
very un-Unix-like.

Me, I'd like to see Plan 9 and Inferno merge -- I see no particular
reason why not, but I don't know much about them. It might not make
any sense. But they're 2 of the most interesting OSes in the last few
decades.

[[e-mail] [hercules-os380]]

Post by Liam Proven ***@gmail.com [hercules-os380]
Paul would learn almost infinitely more by porting Plan 9 to Hercules
than by any amount of retrofitting features to obsolete IBM OSes --
but I don't think it would interest him, sadly.

I'm already learning a hell of a lot of
stuff. But what I think is more valuable
than learning is trying to come up with
solutions to problems, such as adding
AM64 support to MVS 3.8j. Things like
that take an enormous amount of
effort, constantly thinking about C code
running on various platforms. E.g. just
last night I realized, after a lot of thought,
that I could fix the "VM/370 problem" in
cmssupa rather than needing the
operating system itself updated. I posted
the result of that in the VM group a few
hours ago.

I'm not remotely finished with
things like PDPCLIB or PDOS before
starting to get involved with another
operating system.

An operating system that is very
unlikely to make gccmvs compile
faster than MVS, given that the
bottleneck is in the application, not
the operating system, as it should
be. So the benefit is what, exactly?

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
An operating system that is very
unlikely to make gccmvs compile
faster than MVS, given that the
bottleneck is in the application, not
the operating system, as it should
be. So the benefit is what, exactly?

Paul, just asking but you /have/ read
the Lion Book, haven't you?

No, and I did a google search and
couldn't find what you're talking about.

You're not seriously going to challenge
my statement that GCCMVS won't be
any faster when run on Plan 9 compared
to MVS, are you? Assuming identical
hardware.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Paul, just asking but you /have/ read
the Lion Book, haven't you?

No, and I did a google search and
couldn't find what you're talking about.

There's a page on Wikipedia relating to it,
with a link to the text at the bottom.

Why didn't you post a link to it when you
knew I was unable to find it?

Regardless, more google searches and
wikipedia searches and putting in various
lion references, like this one:

https://en.wikipedia.org/wiki/Lions_Book

and disambiguation of "lion" all turned
up nothing.

Post by ***@yahoo.com.au [hercules-os380]
You're not seriously going to challenge
my statement that GCCMVS won't be
any faster when run on Plan 9 compared
to MVS, are you? Assuming identical
hardware.

No, I'm challenging that you're working from a position of profound
ignorance, starting off questionable endeavours without making the
slightest attempt to determine what "prior art" exists or why existing
systems work as they do.

That is the way I work. I don't want to
know how other people implemented
things before I've thought of how I
would do it myself.

Then I compare notes.

If I had researched how 64-bit capability
was added to MVS by IBM I would almost
certainly have come to the conclusion
that we'd reached the end of the MVS/380
technology. Yes, 31-bit was amazing, but
64-bit is totally impossible, because the
PSW needs to increase in size, meaning
that the low memory layout needs to
change, and there is absolutely no
alternative but to modify the MVS source
code, which we don't actually have.

Because I kept my distance from seeing
IBM's implementation for as long as
possible, I had actually wondered what
was required to do, and I thought I could
get it to run with the PSW I already knew.

Note that I waited a very long time for
someone to volunteer to write a very
simple (conceptually) SVC 120 intercept
when all I needed was a few lines of
code in Hercules. I knew too much
about how SVC 120 *actually* worked
in real MVS to realize I could change
the hardware.

I try to avoid getting stuck in a rut like
that as much as possible.

If you prefer to operate differently, that's
fine, but I notice it wasn't you who
outlined how to add 64-bit support for
MVS/380.

Perhaps you shouldn't chide the person
coming up with novel designs so
brazenly.

Just like those who chide America for
various internal alleged deficiencies when
they're the ones who provide the global
security umbrella that the rest of the free
world bludges off. ie don't complain
about the speck in someone else's
eye while ignoring the log in your own.
The only countries who aren't complete
bludgers would probably be the UK,
Georgia and Romania. Australia for
example contributed 1/7 of what the
UK and US contributed to Iraq on a
per capita basis.

BFN. Paul.

[[e-mail] [hercules-os380]]

Paul, just asking but you /have/ read

the Lion Book, haven't you?

which takes you immediately to a page for "Lions' Commentary on UNIX 6th
Edition, with Source Code".

Ok, so the link is in fact:

https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th_Edition,_with_Source_Code

And Googling for '"Lion Book" unix' gives me 'About 2,790 results' of
which at least the first page completely relevant.

I did not add "unix" to the google search
as I had no idea it was related to Unix.
You replied to a comment made about
Plan9, and I didn't even think to add
Plan9 to the search, because it didn't
occur to me that this might be a book
about Plan9 that I was expected to
have read or at least known about.

I actually guessed it was a culture
reference like "The tortoise and the
hare" or "The Young Ones", something
about the philosophy of some lion.

Regardless, I read the above link, and
no, I haven't read it, and no, I don't think
it would be wise for me to read it at this
point in time because it will pollute my
brain with prior art of Unix internals
and possibly lead me to the conclusion
that "this is thus impossible in MVS".

What I am instead interested in doing
is going from the MVS in particular,
and also possibly MSDOS perspective
and start implementing any functionality
that Unix has implemented, e.g. right
at the moment providing a TCP/IP
interface. If TCP/IP on Unix is currently
implemented with the use of fork(), and
that ends up being a show-stopper for
me, so be it. But for the moment I want
to assume that there is nothing stopping
this from being implemented on
MVS 3.8j, and I am willing to start learning
internals of MVS and even z/OS to try
to find the best API to call. You will note
that I already mentioned I don't like the
current Unix interface that has this:

#include <sys/socket.h>

because it implies a directory structure
exists, something that is not mentioned
or required in C90. The first parameter
of fopen() can be anything at all, including
spaces as you see in CMS.

I remember a comment from a friend of
mine about 25 years ago, where he
commented that MVS was good for
some things, but if you wanted to
implement a web server, Unix was
far better. I didn't challenge this
statement, but I also didn't understand
it, even though I had some knowledge
of both systems. Just like I didn't know
what specifically, if anything, was
preventing MVS from handling character
mode terminals.

As I have mentioned before, I have a
goal penciled in to move all of my work
onto MVS, or a PDOS clone of it. ie
I want to do all my web browsing and
everything else from MVS. And run my
BBS on MVS too, which presumably
counts as a web server.

Maybe when I try and fail at this, I will
understand why my friend made his
comment about MVS. And maybe then
Lion's book will be useful to explain why
I failed to get MVS to totally replace
Unix and Windows.

Until then, I'm more interested in MVS
internals than Unix internals, because
it is MVS internals that I want to use
to give Unix and Windows functionality.

And in reverse, I would like Unix and
Windows to provide the same functionality
that MVS does. I can remember asking
a Unix expert on Solaris how I could get
an assembler listing for the Ada compiler
plus a formatted dump with registers
instead of the core file in case I needed to
debug at the assembler level, which I
considered to be a fundamental requirement.
He said there was no way to do that on Unix.
I do not know if there is some sort of
fundamental block in Unix that would
prevent such MVS functionality to be
added, but that's a question for another
day. I'm more interested in getting MVS
to replace Unix before turning around
and getting Unix to replace MVS.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
that Unix has implemented, e.g. right
at the moment providing a TCP/IP
interface. If TCP/IP on Unix is currently
implemented with the use of fork(), and
that ends up being a show-stopper for
me, so be it. But for the moment I want
to assume that there is nothing stopping
this from being implemented on
MVS 3.8j, and I am willing to start learning
internals of MVS and even z/OS to try
to find the best API to call. You will note

And actually I have already penciled in
that TCP/IP probably needs character
mode ability, so I need to start opening
up the concept of character mode
applications and devices on MVS, and
getting micro-emacs to work before
venturing off into TCP/IP seems to me
to be the correct path, rather than the
reverse.

Otherwise I will end up with "character
mode devices ONLY work under
TCP/IP" which offends my sensibilities.

Also note that I am happy if character
mode applications and devices are
restricted for use by a "superuser"
(ie the situation that occurs when
the emulated CPU and the emulated
terminal are running on the same
physical CPU).

Post by ***@yahoo.com.au [hercules-os380]
He said there was no way to do that on Unix.

I misremembered. There was actually no
way of getting "ld" to generate a link map,
which is what I needed to be able to
determine which module had the problem,
and what the offset in that module was.

I don't wish to have a requirement that
debug info must always be retained in
an executable either.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
And actually I have already penciled in
that TCP/IP probably needs character
mode ability, so I need to start opening
up the concept of character mode
applications and devices on MVS, and
getting micro-emacs to work before
venturing off into TCP/IP seems to me
to be the correct path, rather than the
reverse.

And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached.

Post by ***@yahoo.com.au [hercules-os380]
Otherwise I will end up with "character
mode devices ONLY work under
TCP/IP" which offends my sensibilities.

On the other hand, maybe that is
actually exactly what is required.
Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem.

And maybe the TCP/IP interface
can in turn be hidden behind
fopen(). Even if it can, that doesn't
mean it should though. I'm not
sure a complex fwrite() to drop
the DTR on the serial port is
actually reasonable.

On the other hand, maybe that is
just a glorified telnet, where I
assume you can't actually send
a 0xff through by itself anymore,
you need to send two of them
to avoid activating a telnet
command.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached."

Once again, that requires VTAM/NCP which requires a 3705 Front End
Processor that the modem can attach to.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
And actually I have already penciled in
that TCP/IP probably needs character
mode ability, so I need to start opening
up the concept of character mode
applications and devices on MVS, and
getting micro-emacs to work before
venturing off into TCP/IP seems to me
to be the correct path, rather than the
reverse.

And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached.

Post by ***@yahoo.com.au [hercules-os380]
Otherwise I will end up with "character
mode devices ONLY work under
TCP/IP" which offends my sensibilities.

On the other hand, maybe that is
actually exactly what is required.
Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem.
And maybe the TCP/IP interface
can in turn be hidden behind
fopen(). Even if it can, that doesn't
mean it should though. I'm not
sure a complex fwrite() to drop
the DTR on the serial port is
actually reasonable.
On the other hand, maybe that is
just a glorified telnet, where I
assume you can't actually send
a 0xff through by itself anymore,
you need to send two of them
to avoid activating a telnet
command.
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached.

Once again, that requires VTAM/NCP
which requires a 3705 Front End
Processor that the modem can attach to.

I'd like to start from the API.

Using the example of driving a serial
port and dropping DTR, I have the
(paraphrased) following in pdcomm:

PDCOMM pdcomm;

pdcommInit(&pdcomm, "COM2:02F8,3,19200");

pdcommDropDTR(PDCOMM *pdcomm);


That is the init string for MSDOS, but
for the Amiga it is:

"serial.device,0,19200"


What would a suitable init string be
for MVS?

"401,0,19200"

assuming we are driving a serial port
on device 401, connected to a magical
controller on 400 that does absolutely
anything we want? Perhaps a channel
to channel adaptor?

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
What would a suitable init string be
for MVS?
"401,0,19200"

And at the end of the day, any device is
driven by a CCW.

I am tempted to simply have something
like this:

fopen("ccw:401", "r+b");

and an fwrite() results in a Write CCW
and an fread() results in a Read CCW

Although I've never used them as far
as I can remember, there also exists
"control" and "sense", and I'm guessing
that in order to do a "drop DTR" you
would ideally be doing a "control" CCW
with a "drop DTR" as a parameter, and
to check the DTR status you would
really be doing a "sense" CCW and
checking the DTR bit.

So perhaps we really need to start
with an API like:

ccwOpen();
ccwWrite()
ccwRead()
ccwControl()
ccwSense()

and perhaps at a later date we could
actually semi-butcher fwrite() by allowing
for something like:

fwrite("*Hi there");

to do a CCW write of "Hi there"

and

fwrite("+dropdtr");

to do a CCW control of dropping the DTR.


BFN. Paul.

['Dave Wade' [e-mail] [hercules-os380]]

Joe,



Why do you need VTAM. VM/370 managed networking perfectly well with no VTAM for all of its life. VM/SP managed with no VTAM until SP5. What’s wrong with a good old hardwire 2703?



Dave



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 18 September 2017 04:10
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-os380] reimplementing unix








"And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached."



Once again, that requires VTAM/NCP which requires a 3705 Front End Processor that the modem can attach to.



Joe

Post by ***@yahoo.com.au [hercules-os380]
And actually I have already penciled in
that TCP/IP probably needs character
mode ability, so I need to start opening
up the concept of character mode
applications and devices on MVS, and
getting micro-emacs to work before
venturing off into TCP/IP seems to me
to be the correct path, rather than the
reverse.

And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached.

Post by ***@yahoo.com.au [hercules-os380]
Otherwise I will end up with "character
mode devices ONLY work under
TCP/IP" which offends my sensibilities.

On the other hand, maybe that is
actually exactly what is required.
Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem.

And maybe the TCP/IP interface
can in turn be hidden behind
fopen(). Even if it can, that doesn't
mean it should though. I'm not
sure a complex fwrite() to drop
the DTR on the serial port is
actually reasonable.

On the other hand, maybe that is
just a glorified telnet, where I
assume you can't actually send
a 0xff through by itself anymore,
you need to send two of them
to avoid activating a telnet
command.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

Dave,

Paul said:

"Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem."

AFAIK, the only way to do that is with NCP, which requires VTAM. NCP would
speak to an emulated 3172, which could then do an IP ppp/slip connection
over a serial modem.

Joe

Post by 'Dave Wade' ***@gmail.com [hercules-os380]
Joe,
Why do you need VTAM. VM/370 managed networking perfectly well with no
VTAM for all of its life. VM/SP managed with no VTAM until SP5. What’s
wrong with a good old hardwire 2703?
Dave
yahoogroups.com]
*Sent:* 18 September 2017 04:10
*Subject:* Re: [hercules-os380] reimplementing unix
"And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached."
Once again, that requires VTAM/NCP which requires a 3705 Front End
Processor that the modem can attach to.
Joe

Post by ***@yahoo.com.au [hercules-os380]
And actually I have already penciled in
that TCP/IP probably needs character
mode ability, so I need to start opening
up the concept of character mode
applications and devices on MVS, and
getting micro-emacs to work before
venturing off into TCP/IP seems to me
to be the correct path, rather than the
reverse.

And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached.

Post by ***@yahoo.com.au [hercules-os380]
Otherwise I will end up with "character
mode devices ONLY work under
TCP/IP" which offends my sensibilities.

On the other hand, maybe that is
actually exactly what is required.
Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem.
And maybe the TCP/IP interface
can in turn be hidden behind
fopen(). Even if it can, that doesn't
mean it should though. I'm not
sure a complex fwrite() to drop
the DTR on the serial port is
actually reasonable.
On the other hand, maybe that is
just a glorified telnet, where I
assume you can't actually send
a 0xff through by itself anymore,
you need to send two of them
to avoid activating a telnet
command.
BFN. Paul.

[[e-mail] [hercules-os380]]

If you want to strip away levels of complexity and take direct control, why not use use BTAM instead. But better still why try to emulate a serial modem, see if you can use a channel device with a simple interface like a ctca (which is designed for comms with other systems and relatively simple) or a simple device like a card read/punch. I used to work with an IBM SYSTEM/7 linking quite happily to a /370, by pretending to be a card read/punch, without the complications of BTAM or VTAM, just exchanging messages, using card read/write I/o.

[Joe Monk [e-mail] [hercules-os380]]

Card reader? Card Punch? Oh the horrors ....

That would require Paul to use ... OMG ... RECFM=FB. Thats impermissible in
his everything is a text/binary RECFM=V LRECL 32760 world...

Joe

Post by ***@msn.com [hercules-os380]
If you want to strip away levels of complexity and take direct control,
why not use use BTAM instead. But better still why try to emulate a serial
modem, see if you can use a channel device with a simple interface like a
ctca (which is designed for comms with other systems and relatively simple)
or a simple device like a card read/punch. I used to work with an IBM
SYSTEM/7 linking quite happily to a /370, by pretending to be a card
read/punch, without the complications of BTAM or VTAM, just exchanging
messages, using card read/write I/o.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]
Card reader? Card Punch? Oh the horrors ....
That would require Paul to use ... OMG ...
RECFM=FB. Thats impermissible in his
everything is a text/binary RECFM=V
LRECL 32760 world...

I have no idea what you are talking
about. PDPCLIB on MVS fully
supports RECFM=FB and it behaves
appropriately whether you are storing
a text file or a binary file in it.

In fact, in this instance it happens to
behave identically to IBM C.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@msn.com [hercules-os380]
If you want to strip away levels of complexity
and take direct control, why not use use
BTAM instead. But better still why try to
emulate a serial modem, see if you can use
a channel device with a simple interface like
a ctca (which is designed for comms with
other systems and relatively simple) or a

Can I assume the existence of a z/OS
machine with TCP/IP and everything
else you expect z/OS to have, connected
to MVS/380, and then from MVS/380 I
want to access TCP/IP, plus a VT100
that is connected to z/OS via unspecified
means beyond the knowledge of MVS/380.

Can a program running on MVS/380
access all those z/OS devices, and
maybe DASD too?

And then can I replace the z/OS machine
(both hardware and software) with some
other bit of PC software that runs as a
standalone process on Windows 10
instead of being required to embed it
into Hercules/380?

And if that is indeed possible, what
does the actual API look for a normal
application program, running on
MVS/380 (batch or TSO), to access
any of those things - the z/OS TCP/IP,
the z/OS VT100 or the z/OS DASD?

Thanks. Paul.

['Dave Wade' [e-mail] [hercules-os380]]

Joe,

Hercules converts 2703 into tcp/ip into esp8266



 or IBM 8232 LCS, FAL-5798 which was ported to MVS



https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=OC&subtype=NA&htmlfid=897/ENUS5798-FAL&appname=totalstorage

Dave





From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 18 September 2017 17:45
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-os380] reimplementing unix








Dave,



Paul said:



"Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem."



AFAIK, the only way to do that is with NCP, which requires VTAM. NCP would speak to an emulated 3172, which could then do an IP ppp/slip connection over a serial modem.



Joe



On Mon, Sep 18, 2017 at 3:14 AM, 'Dave Wade' ***@gmail.com <mailto:***@gmail.com> [hercules-os380] <hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> > wrote:



Joe,



Why do you need VTAM. VM/370 managed networking perfectly well with no VTAM for all of its life. VM/SP managed with no VTAM until SP5. What’s wrong with a good old hardwire 2703?



Dave



From: hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> [mailto:hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> ]
Sent: 18 September 2017 04:10
To: hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com>
Subject: Re: [hercules-os380] reimplementing unix







"And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached."



Once again, that requires VTAM/NCP which requires a 3705 Front End Processor that the modem can attach to.



Joe

Post by ***@yahoo.com.au [hercules-os380]
And actually I have already penciled in
that TCP/IP probably needs character
mode ability, so I need to start opening
up the concept of character mode
applications and devices on MVS, and
getting micro-emacs to work before
venturing off into TCP/IP seems to me
to be the correct path, rather than the
reverse.

And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached.

Post by ***@yahoo.com.au [hercules-os380]
Otherwise I will end up with "character
mode devices ONLY work under
TCP/IP" which offends my sensibilities.

On the other hand, maybe that is
actually exactly what is required.
Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem.

And maybe the TCP/IP interface
can in turn be hidden behind
fopen(). Even if it can, that doesn't
mean it should though. I'm not
sure a complex fwrite() to drop
the DTR on the serial port is
actually reasonable.

On the other hand, maybe that is
just a glorified telnet, where I
assume you can't actually send
a 0xff through by itself anymore,
you need to send two of them
to avoid activating a telnet
command.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

Dave,

Understood, but that doesnt satisfy the part to "drive a serial port with a
PC-Style modem attached".

Joe

Post by 'Dave Wade' ***@gmail.com [hercules-os380]
Joe,
Hercules converts 2703 into tcp/ip into esp8266


 or IBM 8232 LCS, FAL-5798 which was ported to MVS
https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=
OC&subtype=NA&htmlfid=897/ENUS5798-FAL&appname=totalstorage
Dave
yahoogroups.com]
*Sent:* 18 September 2017 17:45
*Subject:* Re: [hercules-os380] reimplementing unix
Dave,
"Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem."
AFAIK, the only way to do that is with NCP, which requires VTAM. NCP
would speak to an emulated 3172, which could then do an IP ppp/slip
connection over a serial modem.
Joe
Joe,
Why do you need VTAM. VM/370 managed networking perfectly well with no
VTAM for all of its life. VM/SP managed with no VTAM until SP5. What’s
wrong with a good old hardwire 2703?
Dave
yahoogroups.com]
*Sent:* 18 September 2017 04:10
*Subject:* Re: [hercules-os380] reimplementing unix
"And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached."
Once again, that requires VTAM/NCP which requires a 3705 Front End
Processor that the modem can attach to.
Joe

Post by ***@yahoo.com.au [hercules-os380]
And actually I have already penciled in
that TCP/IP probably needs character
mode ability, so I need to start opening
up the concept of character mode
applications and devices on MVS, and
getting micro-emacs to work before
venturing off into TCP/IP seems to me
to be the correct path, rather than the
reverse.

And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached.

Post by ***@yahoo.com.au [hercules-os380]
Otherwise I will end up with "character
mode devices ONLY work under
TCP/IP" which offends my sensibilities.

On the other hand, maybe that is
actually exactly what is required.
Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem.
And maybe the TCP/IP interface
can in turn be hidden behind
fopen(). Even if it can, that doesn't
mean it should though. I'm not
sure a complex fwrite() to drop
the DTR on the serial port is
actually reasonable.
On the other hand, maybe that is
just a glorified telnet, where I
assume you can't actually send
a 0xff through by itself anymore,
you need to send two of them
to avoid activating a telnet
command.
BFN. Paul.

['Dave Wade' [e-mail] [hercules-os380]]

Joe,

How does VTAM allow that?

Dave



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: 19 September 2017 03:54
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-os380] reimplementing unix








Dave,



Understood, but that doesnt satisfy the part to "drive a serial port with a PC-Style modem attached".



Joe



On Mon, Sep 18, 2017 at 3:50 PM, 'Dave Wade' ***@gmail.com <mailto:***@gmail.com> [hercules-os380] <hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> > wrote:



Joe,

Hercules converts 2703 into tcp/ip into esp8266



 or IBM 8232 LCS, FAL-5798 which was ported to MVS



https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=OC <https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=OC&subtype=NA&htmlfid=897/ENUS5798-FAL&appname=totalstorage> &subtype=NA&htmlfid=897/ENUS5798-FAL&appname=totalstorage

Dave





From: hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> [mailto:hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> ]
Sent: 18 September 2017 17:45
To: hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com>
Subject: Re: [hercules-os380] reimplementing unix







Dave,



Paul said:



"Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem."



AFAIK, the only way to do that is with NCP, which requires VTAM. NCP would speak to an emulated 3172, which could then do an IP ppp/slip connection over a serial modem.



Joe



On Mon, Sep 18, 2017 at 3:14 AM, 'Dave Wade' ***@gmail.com <mailto:***@gmail.com> [hercules-os380] <hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> > wrote:



Joe,



Why do you need VTAM. VM/370 managed networking perfectly well with no VTAM for all of its life. VM/SP managed with no VTAM until SP5. What’s wrong with a good old hardwire 2703?



Dave



From: hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> [mailto:hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> ]
Sent: 18 September 2017 04:10
To: hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com>
Subject: Re: [hercules-os380] reimplementing unix





"And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached."



Once again, that requires VTAM/NCP which requires a 3705 Front End Processor that the modem can attach to.



Joe

Post by ***@yahoo.com.au [hercules-os380]
And actually I have already penciled in
that TCP/IP probably needs character
mode ability, so I need to start opening
up the concept of character mode
applications and devices on MVS, and
getting micro-emacs to work before
venturing off into TCP/IP seems to me
to be the correct path, rather than the
reverse.

And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached.

Post by ***@yahoo.com.au [hercules-os380]
Otherwise I will end up with "character
mode devices ONLY work under
TCP/IP" which offends my sensibilities.

On the other hand, maybe that is
actually exactly what is required.
Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem.

And maybe the TCP/IP interface
can in turn be hidden behind
fopen(). Even if it can, that doesn't
mean it should though. I'm not
sure a complex fwrite() to drop
the DTR on the serial port is
actually reasonable.

On the other hand, maybe that is
just a glorified telnet, where I
assume you can't actually send
a 0xff through by itself anymore,
you need to send two of them
to avoid activating a telnet
command.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

Dave,

Doesnt hercules have an emulated 3705 in comm3705.c? The 3705 is a VTAM/NCP
device... with the added bonus of 2703 emulation.

So, using that, he can connect a modem to the serial port of the hercules
PC and when the BBS client connects, the client gets a local IP via
PPP/SLIP. Since the client now is on the hercules local IP network, the
client can connect to the IP:port of the 3705 to get service (telnet for
TTY/LU1, tn3270 for LU2) ... when done the client hangs up and the modem
resets and waits for the next call.

Reading the code for comm3705.c it says it supports a single LU1 (TTY)
session or a single LU2(3270) session... The LU1 path would allow him to
customize his telix client zmodem file transfer package.

Also, if he wanted to, he could modify comm3705 to directly drive a VTAM
defined type II port, which could be mapped onto a PC serial port directly.

Seems like that solves everything he wants to do, no? Or am I
oversimplifying it?

Joe

Post by 'Dave Wade' ***@gmail.com [hercules-os380]
Joe,
How does VTAM allow that?
Dave
yahoogroups.com]
*Sent:* 19 September 2017 03:54
*Subject:* Re: [hercules-os380] reimplementing unix
Dave,
Understood, but that doesnt satisfy the part to "drive a serial port with
a PC-Style modem attached".
Joe
Joe,
Hercules converts 2703 into tcp/ip into esp8266


 or IBM 8232 LCS, FAL-5798 which was ported to MVS
https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=
OC&subtype=NA&htmlfid=897/ENUS5798-FAL&appname=totalstorage
Dave
yahoogroups.com]
*Sent:* 18 September 2017 17:45
*Subject:* Re: [hercules-os380] reimplementing unix
Dave,
"Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem."
AFAIK, the only way to do that is with NCP, which requires VTAM. NCP
would speak to an emulated 3172, which could then do an IP ppp/slip
connection over a serial modem.
Joe
Joe,
Why do you need VTAM. VM/370 managed networking perfectly well with no
VTAM for all of its life. VM/SP managed with no VTAM until SP5. What’s
wrong with a good old hardwire 2703?
Dave
yahoogroups.com]
*Sent:* 18 September 2017 04:10
*Subject:* Re: [hercules-os380] reimplementing unix
"And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached."
Once again, that requires VTAM/NCP which requires a 3705 Front End
Processor that the modem can attach to.
Joe

Post by ***@yahoo.com.au [hercules-os380]
And actually I have already penciled in
that TCP/IP probably needs character
mode ability, so I need to start opening
up the concept of character mode
applications and devices on MVS, and
getting micro-emacs to work before
venturing off into TCP/IP seems to me
to be the correct path, rather than the
reverse.

And note that I don't just want emacs
to work, I want my BBS software
running on MVS to also drive a serial
port with a PC-style modem attached.

Post by ***@yahoo.com.au [hercules-os380]
Otherwise I will end up with "character
mode devices ONLY work under
TCP/IP" which offends my sensibilities.

On the other hand, maybe that is
actually exactly what is required.
Everything gets channeled via
a TCP/IP interface and some
other bit of software is required
to convert that into driving an
actual serial modem.
And maybe the TCP/IP interface
can in turn be hidden behind
fopen(). Even if it can, that doesn't
mean it should though. I'm not
sure a complex fwrite() to drop
the DTR on the serial port is
actually reasonable.
On the other hand, maybe that is
just a glorified telnet, where I
assume you can't actually send
a 0xff through by itself anymore,
you need to send two of them
to avoid activating a telnet
command.
BFN. Paul.

[[e-mail] [hercules-os380]]

Dave,
Doesnt hercules have an emulated 3705 in comm3705.c? The 3705 is a VTAM/NCP device... with the added
bonus of 2703 emulation.
. . .
Reading the code for comm3705.c it says it supports a single LU1 (TTY) session or a single LU2(3270)
session... The LU1 path would allow him to customize his telix client zmodem file transfer package.

Exactly this setup (with the exception of not bridging to a physical modem) is demonstrated in TK4- for use with KERMIT. So, one can easily start using this setup and develop it to whatever deems fit (basically, exchanging KERMIT with a reasonable implementation of ZMODEM should do). TSO HELP member KERMIT provides the information necessary to get started.


Cheers
JÃŒrgen


P.S.: To add something real to this metaphysics discussion, here an example (sorry for the amount of output, that thing really is a bit chatty):


***@wotho3u:~$ kermit

C-Kermit 9.0.302 OPEN SOURCE:, 20 Aug 2011, for Linux+SSL+KRB5

Copyright (C) 1985, 2011,

Trustees of Columbia University in the City of New York.

Type ? or HELP for help.

(/home/juergen/) C-Kermit>telnet 127.0.0.1 37051

Trying 127.0.0.1... Reverse DNS Lookup... (OK)

Connecting to host localhost:37051

Escape character: Ctrl-\ (ASCII 28, FS): enabled

Type the escape character followed by C to get back,

or followed by ? to see other options.

----------------------------------------------------

Hercules version 4.00 built on Jun 3 2017 19:04:00

running on (-. UP)

Connected to device 000

127.0.0.1:53139 VTAM CONNECTION ACCEPTED - NETWORK NODE= 4015

Enter logon command for application TSO

Enter command> logon user01

Connecting to TSO
IKJ56714A ENTER CURRENT PASSWORD FOR USER01-
IKJ56455I USER01 LOGON IN PROGRESS AT 17:06:04 ON SEPTEMBER 19, 2017

IKJ56951I NO BROADCAST MESSAGES

...

... (some messages skipped)

...

There's so much plastic in this culture that vinyl leopard skin

is becoming an endangered synthetic.

-- Lily Tomlin


Another bit of wisdom from the fortune cookie jar

...

... (some messages skipped)

...

READY

kermit

Type 0 long packets specified

Kermit-TSO Version 4.0 (88/5/18)

Enter ? for a list of valid commands



Kermit-TSO>set file-type text

Kermit-TSO>send 'sys2.help(kermit)'

Kermit-TSO ready to send.

Please escape to local Kermit now to RECEIVE the file(s).


(Back at wotho3u)

----------------------------------------------------

(/home/juergen/) C-Kermit>receive kermit.txt

(/home/juergen/) C-Kermit>C

Connecting to host localhost:37051

Escape character: Ctrl-\ (ASCII 28, FS): enabled

Type the escape character followed by C to get back,

or followed by ? to see other options.

----------------------------------------------------

Kermit-TSO>stat

1 file sent last.

Bytes/pkt: S=874 R=9 requiring 32 pkt

Bytes/sec: S=799 R=8 requiring 35 sec

Disk bytes/sec: 1856

1 repeat packets sent

Optimum packet size: 672

No errors

Kermit-TSO>quit

READY

logoff

IKJ56470I USER01 LOGGED OFF TSO AT 17:08:15 ON SEPTEMBER 19, 2017

******

Enter logon command for application TSO

Enter command> #release

Disconnected, SSCP - LU (stick man) session now active

127.0.0.1:53139 VTAM CONNECTION TERMINATED


Communications disconnect (Back at wotho3u)

----------------------------------------------------

(/home/juergen/) C-Kermit>stat


protocol : Kermit

status : SUCCESS

damaged packets rec'd : 0

timeouts : 0

retransmissions : 0

window slots used : 1 of 30

reliable: : not negotiated

clearchannel: : not negotiated

elapsed time : 00:00:02 (1.530 sec)

effective data rate : 19478 cps


Use STATISTICS /VERBOSE for greater detail.


(/home/juergen/) C-Kermit>quit

***@wotho3u:~$ ls -l kermit.txt

-rw-r--r-- 1 juergen juergen 29797 Sep 19 17:04 kermit.txt

***@wotho3u:~$ head -n 8 kermit.txt

)F FUNCTION -


The KERMIT command invokes Kermit-TSO, an assembly language program

which implements the Kermit file transfer protocol on IBM System/370

and XA mainframe computers and compatibles running the MVS (Multiple

Virtual Storage) operating system with the TSO (Time Sharing Option)

subsystem. Kermit-TSO supports file transfer in both line-mode and

full-screen operation.

***@wotho3u:~$

[[e-mail] [hercules-os380]]

Post by ***@id.ethz.ch [hercules-os380]
Exactly this setup (with the exception
of not bridging to a physical modem)
is demonstrated in TK4- for use with
KERMIT.

If it was bridged to a physical modem,
how would the BBS issue a "drop DTR"?

Post by ***@id.ethz.ch [hercules-os380]
So, one can easily start using this setup
and develop it to whatever deems fit
(basically, exchanging KERMIT with a
reasonable implementation of ZMODEM
should do).

And how would the BBS instruct the
hardware to switch on character mode
instead of line mode, so that the
various zmodem buffers can come
through without any terminating CRLF?

Or is the BBS required to drive a
TCP/IP connection always, not a
serial port? Is a serial port still
semi-impossible?

Thanks. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"If it was bridged to a physical modem,
how would the BBS issue a "drop DTR"?"

By telling VTAM to drop the connection. Since modems are switched nodes in
VTAM, once the connection is dropped, VTAM kills the serial port.

"And how would the BBS instruct the
hardware to switch on character mode
instead of line mode, so that the
various zmodem buffers can come
through without any terminating CRLF?"

The BBS wouldn't instruct the hardware to switch to character mode. As you
will notice from Jurgens example, KERMIT is implemented under TSO ... in
line mode.

Your "BBS" will be its own VTAM application, just like TSO is a VTAM
application. Then, once you open the connection (ACB), VTAM will simply
pass the data back and forth to you, just like reading and writing data to
a file. What happens to the data is up to you.

"Or is the BBS required to drive a
TCP/IP connection always, not a
serial port? Is a serial port still
semi-impossible?"

As I pointed out earlier, it is perfectly possible to drive a serial port
from hercules. You must modify the hercules code in comm3705.c to add in
serial port functionality as VTAM expects it ... a type II port which can
operate at up to 57600 bps. Once you've done that, you can use an LU1
stream (TTY) via the 2703 emulation contained in a 3705 between your BBS
application and the terminal.

In other words, your BBS application replaces TSO as the TP monitor. You
have to modify the current hercules hardware driver to add in serial port
functionality (doesnt exist now), and use the MVS supplied access method
(VTAM) to define it and drive it from MVS. Then, instead of logging on to
TSO under VTAM, you would logon to your BBS under VTAM and any data
processing is up to you.

None of that is rocket science and can easily be found in the VTAM manuals
as to how to implement it. Its actually pretty standard stuff.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@id.ethz.ch [hercules-os380]
Exactly this setup (with the exception
of not bridging to a physical modem)
is demonstrated in TK4- for use with
KERMIT.

If it was bridged to a physical modem,
how would the BBS issue a "drop DTR"?

Post by ***@id.ethz.ch [hercules-os380]
So, one can easily start using this setup
and develop it to whatever deems fit
(basically, exchanging KERMIT with a
reasonable implementation of ZMODEM
should do).

And how would the BBS instruct the
hardware to switch on character mode
instead of line mode, so that the
various zmodem buffers can come
through without any terminating CRLF?
Or is the BBS required to drive a
TCP/IP connection always, not a
serial port? Is a serial port still
semi-impossible?
Thanks. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
If it was bridged to a physical modem,
how would the BBS issue a "drop DTR"?

By telling VTAM to drop the connection.

This bypasses my question, so let me ask
a different question.

If I want to change the serial port (or
is it modem? or both?) to N,8,1, under
OS/2 I would do this:

void pdcommSetParms(PDCOMM *pdcomm, int parity, int data, int stop)
{
APIRET rc;
struct {
BYTE data;
BYTE parity;
BYTE stop;
} lineCharacter;

lineCharacter.data = (BYTE)data;
lineCharacter.parity = (BYTE)parity;
if (stop == 1)
{
stop = 0;
}
lineCharacter.stop = (BYTE)stop;
rc = DosDevIOCtl(pdcomm->hfile,
IOCTL_ASYNC,
0x42,
&lineCharacter,
sizeof lineCharacter,
NULL,
NULL,
0,
NULL);


ie the crucial bit is I call:

DosDevIOCtl()

This is for a device (COM1) that I
have opened using DosOpen() and
would normally write to using
DosWrite(). ie the existence of a
"control" vs "write" exists. The
concept exists.

I'm not familiar with TCP/IP, although
I do know that write() works to send
data. I don't know if there is a TCP/IP
call that does the equivalent of
DosDevIOCtl(). Without that control,
I can't manipulate the serial port via
TCP/IP.

So one question is whether TCP/IP
has a "control" call.

The next question is that I expect to
be able to manipulate a serial port
from MVS, if I have suitable hardware
(ie make Herc mods). But regardless
of the Herc mods, I need an API for
my BBS or Telix or pdptel (all ported
to MVS) to call to open, write, and
control a serial port.

You have mentioned VTAM. Does
VTAM in MVS 3.8j contain an API
that allows me to do all those functions,
ie open, write and control a device.
In addition, when I do a write of a
single character, like the letter 'A',
I expect it to be delivered to the
serial port immediately, not be line
buffered. Will VTAM allow that?
ie will VTAM allow me to switch from
line mode to character mode, the same
way C90 does?

And finally, is it possible to drive a
serial port that is actually attached
to a different system, possibly running
z/OS, via a channel to channel
adapter? ie can I use the VTAM API
on my current MVS 3.8j system, and
have VTAM automatically package
up my request to drive the serial port
and send it across the channel to
channel adapter instead of manipulating
hardware on this current machine it is
running on?

Thanks. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"Does
VTAM in MVS 3.8j contain an API
that allows me to do all those functions,
ie open, write and control a device."

Yes. It is available via the VTAM macros.

VTAM is to comms hardware (FEP, controllers and terminals) what QSAM is to
files.

You have an ACB, a NIB, an RPL, all of which are control blocks that can be
manipulated just like DCBs can in QSAM.

"In addition, when I do a write of a
single character, like the letter 'A',
I expect it to be delivered to the
serial port immediately, not be line
buffered. Will VTAM allow that?"

Your native VTAM application can do that, yes. Line buffering is a function
of TSO. Think about CICS. Is it line buffered? No, because it is a VTAM
app.

Think about credit card authorizations. Credit card terminals (start-stop)
can dial into a mainframe and send/receive data to get charge approvals.

So in much the same way, as a credit card application, you have to write a
native VTAM application that does terminal I/O the way you want.

For a start-stop terminal (LU1 device), you can use the PROC=CONTinuous
options to achieve this.

"And finally, is it possible to drive a
serial port that is actually attached
to a different system, possibly running
z/OS, via a channel to channel
adapter? ie can I use the VTAM API
on my current MVS 3.8j system, and
have VTAM automatically package
up my request to drive the serial port
and send it across the channel to
channel adapter instead of manipulating
hardware on this current machine it is
running on?"

Not directly. VTAM is also about networking. A terminal connected to system
'A' can access applications on system 'B'. So your VTAM app on system 'B'
would issue a CLSDST (close terminal) command to drop the connection with
terminal on system 'A'. The VTAM on system 'A' will then take the
necessary action (i.e. drop DTR) and tell the app on system 'B' when the
connection has been dropped.

http://www.bitsavers.org/pdf/ibm/sna/vtam/GC27-6995-0_VTAM_Application_Programmers_Reference_Apr73.pdf

Also, have a look at page 179 in this:

http://www.prycroft6.com.au/misc/download/GC28-0688-2_SPL_VTAM_Level2_Dec77OCR.pdf

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
If it was bridged to a physical modem,
how would the BBS issue a "drop DTR"?

By telling VTAM to drop the connection.

This bypasses my question, so let me ask
a different question.
If I want to change the serial port (or
is it modem? or both?) to N,8,1, under
void pdcommSetParms(PDCOMM *pdcomm, int parity, int data, int stop)
{
APIRET rc;
struct {
BYTE data;
BYTE parity;
BYTE stop;
} lineCharacter;
lineCharacter.data = (BYTE)data;
lineCharacter.parity = (BYTE)parity;
if (stop == 1)
{
stop = 0;
}
lineCharacter.stop = (BYTE)stop;
rc = DosDevIOCtl(pdcomm->hfile,
IOCTL_ASYNC,
0x42,
&lineCharacter,
sizeof lineCharacter,
NULL,
NULL,
0,
NULL);
DosDevIOCtl()
This is for a device (COM1) that I
have opened using DosOpen() and
would normally write to using
DosWrite(). ie the existence of a
"control" vs "write" exists. The
concept exists.
I'm not familiar with TCP/IP, although
I do know that write() works to send
data. I don't know if there is a TCP/IP
call that does the equivalent of
DosDevIOCtl(). Without that control,
I can't manipulate the serial port via
TCP/IP.
So one question is whether TCP/IP
has a "control" call.
The next question is that I expect to
be able to manipulate a serial port
from MVS, if I have suitable hardware
(ie make Herc mods). But regardless
of the Herc mods, I need an API for
my BBS or Telix or pdptel (all ported
to MVS) to call to open, write, and
control a serial port.
You have mentioned VTAM. Does
VTAM in MVS 3.8j contain an API
that allows me to do all those functions,
ie open, write and control a device.
In addition, when I do a write of a
single character, like the letter 'A',
I expect it to be delivered to the
serial port immediately, not be line
buffered. Will VTAM allow that?
ie will VTAM allow me to switch from
line mode to character mode, the same
way C90 does?
And finally, is it possible to drive a
serial port that is actually attached
to a different system, possibly running
z/OS, via a channel to channel
adapter? ie can I use the VTAM API
on my current MVS 3.8j system, and
have VTAM automatically package
up my request to drive the serial port
and send it across the channel to
channel adapter instead of manipulating
hardware on this current machine it is
running on?
Thanks. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
Does
VTAM in MVS 3.8j contain an API
that allows me to do all those functions,
ie open, write and control a device.
Yes. It is available via the VTAM macros.

So to set a serial port to N,8,1, what
call do I need? I looked at the index of
both manuals you sent me and didn't
see the required call.

Post by ***@yahoo.com.au [hercules-os380]
VTAM is to comms hardware (FEP, controllers
and terminals) what QSAM is to files.

I see. I guess I need to take a step back
first then. What about if I want to manipulate
an arbitrary device, perhaps a USB stick,
rather than something that can be forced
to look like a terminal?

Is it fair to say that that would be done by
CCWs, and that the equivalent of the
open/write/control that I need is:

open: no equivalent, no such concept
write: write
control: control

as seen on the top of page 28 of the
S/370 Reference Card GX20-1850-7?

So with the USB stick I may want to
use "control" to tell it to prioritize data
transfer over "first in".

And to write a particular sector I would
use "write". Although wouldn't that
depend on whether the write CCW
knew about things such as sector
numbers?

I have just taken a look at the PDOS/370
assembler code, and it seems that the
way it works is that an SIO is issued to
a particular device number, and is
designed to access FLCCAW which
points to a series of commands which
are likely to be device-specific.

As such, I'm not sure whether it makes
sense to differentiate between a "write"
and "control" CCW. I'm not sure if
"search" is considered to be control
and "write" has the actual data.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
first then. What about if I want to manipulate
an arbitrary device, perhaps a USB stick,

Note that if you are going to avoid
answering this question by saying
that USB is just another type of
disk drive so should go through
the existing logic, then pick a
different device. Maybe a wireless
adapter that can be used to
communicate with my router.

Or if that still avoids the question,
then how about a light bulb connected
to my computer via USB stick, and
the light bulb has 5 different intensity
settings, so I need to be able to send
a command to the light bulb with a
parameter that could be from 0 to 5.

Should such a command be a write
or a control?

What changes would need to be made
to the light bulb hardware such that
*both* write and control need to exist
as two distinct concepts?

What makes a light bulb fit into a write
or a control? Why does a light-bulb+
have these 2 distinct things, and not
e.g. have 3 distinct things or just 1
distinct thing? I guess "sense" could
be another thing? To see what the
current intensity setting is? Should it
be "sense" or "read" and why? Has
IBM covered every possible concept
on page 28 of the S/370 Reference
Card? I see there is a "Control No
Operation" listed. I would never have
guessed that such a thing would be
required when implementing hardware.
ie if this is actually useful, and I was
the designer, I would have come up
with a lousy design because this
concept does not exist in my brain.

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I see. I guess I need to take a step back
first then. What about if I want to manipulate
an arbitrary device, perhaps a USB stick,
rather than something that can be forced
to look like a terminal?
Is it fair to say that that would be done by
CCWs, and that the equivalent of the

VTAM was designed to eliminate as much device dependency from the
processing program as feasible, and let the front-end processor handle
details of character set, speed, etc. as possible (we had a separate
rotary for ASCII start-stop and EBCDIC start-stop, but to the
application they looked as the same NTO). The last & only chance over
control information is in the BIND negotiation at LOGON exit time.
AFAIK, the characteristics (parity, speed, etc.) are not part of that
negotiation.

Our NCR/Comtens required the user to hit ENTER one or more times, and
the FEP used that bit stream to determine speed and parity. While there
is also dial-out support, I'm not sure how to force specific settings
from the mainframe.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Tony Harminc [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I see. I guess I need to take a step back
first then. What about if I want to manipulate
an arbitrary device, perhaps a USB stick,
rather than something that can be forced
to look like a terminal?
Is it fair to say that that would be done by CCWs,

It depends. If you are talking about the S/370 architecture, then the
only two schemes for talking to devices off the box are CCW-based I/O
and, as I've previously pointed out, the Read Direct/Write Direct
instructions. The latter were optional and rarely used, but
architecturally for an emulator like Hercules would be an intriguing
approache to specialized I/O. The big down side is that the opcodes
were repurposed in S/390 for the BRXH/BRXLE instructions, which have
been retrofitted to Hercules S/370 in violation of the PofO.

If you are talking of later IBM architectures, there are other
interfaces to the outside world, such as QDIO (used for network
access), the coupling facility, and various others, all of which are
little or not at all documented.

Post by ***@yahoo.com.au [hercules-os380]
As such, I'm not sure whether it makes
sense to differentiate between a "write"
and "control" CCW. I'm not sure if
"search" is considered to be control
and "write" has the actual data.

Yes, that is the case.

Tony H.

[Tony Harminc [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
If I want to change the serial port (or
is it modem? or both?) to N,8,1, under
void pdcommSetParms(PDCOMM *pdcomm, int parity, int data, int stop)
{
APIRET rc;
struct {
BYTE data;
BYTE parity;
BYTE stop;
} lineCharacter;
lineCharacter.data = (BYTE)data;
lineCharacter.parity = (BYTE)parity;
if (stop == 1)
{
stop = 0;
}
lineCharacter.stop = (BYTE)stop;
rc = DosDevIOCtl(pdcomm->hfile,
IOCTL_ASYNC,
0x42,
&lineCharacter,
sizeof lineCharacter,
NULL,
NULL,
0,
NULL);
DosDevIOCtl()
This is for a device (COM1) that I
have opened using DosOpen() and
would normally write to using
DosWrite(). ie the existence of a
"control" vs "write" exists. The
concept exists.

As it does in UNIX. You would typically open a serial device like
/dev/tty1 or something, or for that matter /dev/sd1 which would be a
disk. Then you would read and write using read() and write(). To
control the device, you would use ioctl() or one of its variants. So
it sounds very similar to what OS2 does.

Post by ***@yahoo.com.au [hercules-os380]
I'm not familiar with TCP/IP, although
I do know that write() works to send
data. I don't know if there is a TCP/IP
call that does the equivalent of
DosDevIOCtl(). Without that control,
I can't manipulate the serial port via
TCP/IP.

No, there isn't. Your conceptual model is all muddled here. TCP/IP
doesn't deal with devices like serial ports. Or rather, there are no
TCP/IP APIs to deal with such devices; obviously a TCP/IP
implementation can use a serial port as part of its transport scheme,
but that part is not exposed to application programs at the other end
of the TCP/IP stack.*

* Well, a TCP/IP implementation could provide administrative APIs to
control devices, but these would be non-standard.

Post by ***@yahoo.com.au [hercules-os380]
So one question is whether TCP/IP
has a "control" call.

Yes, but not to control things like a serial port. It controls various
aspect of socket processing. Sockets are not "devices" in the sense
you mean. Think of it this way: do you expect when you read/write a
UNIX file that there is a control call to tell the disk drive that
your file happens to be on to use a particular internal buffering
algorithm, to prefer performance to noise level, and so on? I think
not; it's outside the scope of an API set that deals with files.

On z/OS the socket control call is w_ioctl() . That may well be a UNIX standard.

Post by ***@yahoo.com.au [hercules-os380]
The next question is that I expect to
be able to manipulate a serial port
from MVS, if I have suitable hardware
(ie make Herc mods). But regardless
of the Herc mods, I need an API for
my BBS or Telix or pdptel (all ported
to MVS) to call to open, write, and
control a serial port.

OK. But don't muddle that with TCP/IP API calls. If you want to
control a device, then open that device, and then use the appropriate
control call. It is not a failing in TCP/IP that it doesn't do this
kind of thing.

Post by ***@yahoo.com.au [hercules-os380]
And finally, is it possible to drive a
serial port that is actually attached
to a different system, possibly running
z/OS, via a channel to channel
adapter? ie can I use the VTAM API
on my current MVS 3.8j system, and
have VTAM automatically package
up my request to drive the serial port
and send it across the channel to
channel adapter instead of manipulating
hardware on this current machine it is
running on?

I don't know about VTAM for this, but it's a perfectly reasonable
thing to want to do, and not uncommon. For example, I have a box here
that does just that via TCP/IP. It's one of these:
https://ww2.systech.com/nds6000 My box is a model 6104. (There are
also similar boxes that map USB on one side to RS232 serial on the
other.)

It lives on a TCP/IP network, and has four RS232-C serial ports with
DB9 connectors. The box also has a little web server with an admin GUI
that allows you to control the port speed, parity bits, flow control,
etc. and even change the ports between RS232 and RS422/486. So you can
plug a port into a dialup modem, use the GUI to map a TCP port on the
network side to that port, telnet (or raw - it's configurable) to that
port on the box, and there you have it.

Anyone can connect to it over the network, subject to security
controls, of course. I can put it up on the public Internet and you
can play with it if you like, though I'm not sure if I still have a
dialup modem to plug it into. But I'm sure I have other serial devices
that would work.

Of course you can implement exactly the same thing on a PC running
UNIX or Windows or OS2 or whatever. You write a little program that
talks TCP on one side, and uses that DosDevIOCtl() or similar to set
up the port. Then you copy data in both directions between socket and
serial port.

You'll notice the slight difference between what you (seem to) want,
and what my box does. Configuring the serial port is done out-of-band
via a GUI, but you probably want it in-band. You could do this in
several ways: one would he Hayes-style where you look for +++ or the
like and then accept commands; another would be to use the TCP
facility for having an out-of-band channel as part of the same TCP
connection (I believe telnet uses this to implement things like
Break), or of course you could have a separate TCP connection used
just for "control" calls, but one that's less user-friendly (GUI) and
more program-friendly.

Tony H.

[[e-mail] [hercules-os380]]

Post by Tony Harminc ***@gmail.com [hercules-os380]
via a GUI, but you probably want it in-band. You could do this in
several ways: one would he Hayes-style where you look for +++ or the
like and then accept commands; another would be to use the TCP
facility for having an out-of-band channel as part of the same TCP
connection (I believe telnet uses this to implement things like
Break), or of course you could have a separate TCP connection used
just for "control" calls, but one that's less user-friendly (GUI) and
more program-friendly.

Thankyou. This is at a level that I understand.

Next challenge is to understand how to do it
without using TCP/IP.

At the end of the day I want to be able to do,
and understand, both, on MVS in particular
but also generically.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Tony Harminc ***@gmail.com [hercules-os380]
via a GUI, but you probably want it in-band. You could do this in
several ways: one would he Hayes-style where you look for +++ or the
like and then accept commands; another would be to use the TCP
facility for having an out-of-band channel as part of the same TCP
connection (I believe telnet uses this to implement things like
Break), or of course you could have a separate TCP connection used
just for "control" calls, but one that's less user-friendly (GUI) and
more program-friendly.

The fact that you would break out into
a separate TCP connection for control
calls surely highlights a failure in the
TCP/IP protocol to distinguish between
a write and a control?

It shouldn't be necessary to fudge the
data to look for "+++".

Either that, or there should have been
yet another layer added on top of TCP/IP
that sends all information with a header
to say whether the data that follows is
a control, a write, a read or a sense.
And maybe a "control no-op", whatever
that is???

Post by Tony Harminc ***@gmail.com [hercules-os380]
Yes, but not to control things like a serial port. It controls various
aspect of socket processing. Sockets are not "devices" in the sense
you mean. Think of it this way: do you expect when you read/write a
UNIX file that there is a control call to tell the disk drive that
your file happens to be on to use a particular internal buffering
algorithm, to prefer performance to noise level, and so on? I think
not; it's outside the scope of an API set that deals with files.

But if I use fopen() to open "COM1", then yes,
I am in need of a further API to set the N,8,1.

I can imagine the need of the operating system
being able to open the disk drive /dev/hd0
and then setting the noise levels too. This
could potentially be done via fopen() too.
You could argue that it is a failure in C90
to specify how to send a "control" to a
file opened via fopen(). Read and write
operations have been defined, and even
a "note position" and "seek" have been
defined - hell, double-defined in fact
(ie both fseek() and fsetpos()).

Perhaps C90 needs to be updated to
include something similar to ioctl(), if
they haven't already done so in C99
or C11.

Post by Tony Harminc ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
The next question is that I expect to
be able to manipulate a serial port
from MVS, if I have suitable hardware
(ie make Herc mods). But regardless
of the Herc mods, I need an API for
my BBS or Telix or pdptel (all ported
to MVS) to call to open, write, and
control a serial port.

OK. But don't muddle that with TCP/IP API calls. If you want to
control a device, then open that device, and then use the appropriate
control call. It is not a failing in TCP/IP that it doesn't do this
kind of thing.

Surely it is a failure in both TCP/IP and C90
to not cater for "control" commands for an
open device-connected socket and a
local device respectively?

Or perhaps the next layer that should be
added to TCP/IP is the telnet protocol,
and it is at that level that the IAC can be
sent to a device to do the equivalent of
ioctl()? ie instead of using arbitrary
characters like +++ it should be the
well-defined IAC? So we can stick with
a simple write() after all, no need for
an ioctl()? And ditto with fwrite after
an fopen("/dev/hd0") - we should be
careful, when writing, to double every
IAC character to prevent it from doing
a control of the device being written to?
Who should be doubling the IAC
characters? The application or fwrite()?

Perhaps what we need is:

fopen("/dev/hd0,telnet", "r+b");

when manipulating a device, and somewhere
(where?) needs to be added code to convert an:

IAC N,8,1

into an actual ioctl() of the serial port to
set N,8,1.

Or perhaps a:

fopen("/dev/hd0,telnet-clib", "r+b");

to get the C library to double the IAC
characters in fwrite, and a:

fopen("/dev/hd0,telnet-app", "r+b");

to allow the application program to take
care of doubling the IAC characters when
data is being written (in an application
that also issues control commands).

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"Or perhaps the next layer that should be
added to TCP/IP is the telnet protocol"

Telnet is an application, not a protocol (Layer 7).

TCP is a protocol (Layer 4).
IP is a protocol (Layer 3).

"Surely it is a failure in both TCP/IP and C90
to not cater for "control" commands for an
open device-connected socket and a
local device respectively?"

How is it a failure of a protocol to provide for something that belongs to
the upper layers? TCP is layer 4, IP is layer 3... how is it their failure
to provide for something that belongs at layers 5 (session), layer 6
(presentation) or layer 7 (application)?

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Tony Harminc ***@gmail.com [hercules-os380]
via a GUI, but you probably want it in-band. You could do this in
several ways: one would he Hayes-style where you look for +++ or the
like and then accept commands; another would be to use the TCP
facility for having an out-of-band channel as part of the same TCP
connection (I believe telnet uses this to implement things like
Break), or of course you could have a separate TCP connection used
just for "control" calls, but one that's less user-friendly (GUI) and
more program-friendly.

The fact that you would break out into
a separate TCP connection for control
calls surely highlights a failure in the
TCP/IP protocol to distinguish between
a write and a control?
It shouldn't be necessary to fudge the
data to look for "+++".
Either that, or there should have been
yet another layer added on top of TCP/IP
that sends all information with a header
to say whether the data that follows is
a control, a write, a read or a sense.
And maybe a "control no-op", whatever
that is???

Post by Tony Harminc ***@gmail.com [hercules-os380]
Yes, but not to control things like a serial port. It controls various
aspect of socket processing. Sockets are not "devices" in the sense
you mean. Think of it this way: do you expect when you read/write a
UNIX file that there is a control call to tell the disk drive that
your file happens to be on to use a particular internal buffering
algorithm, to prefer performance to noise level, and so on? I think
not; it's outside the scope of an API set that deals with files.

But if I use fopen() to open "COM1", then yes,
I am in need of a further API to set the N,8,1.
I can imagine the need of the operating system
being able to open the disk drive /dev/hd0
and then setting the noise levels too. This
could potentially be done via fopen() too.
You could argue that it is a failure in C90
to specify how to send a "control" to a
file opened via fopen(). Read and write
operations have been defined, and even
a "note position" and "seek" have been
defined - hell, double-defined in fact
(ie both fseek() and fsetpos()).
Perhaps C90 needs to be updated to
include something similar to ioctl(), if
they haven't already done so in C99
or C11.

Post by Tony Harminc ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
The next question is that I expect to
be able to manipulate a serial port
from MVS, if I have suitable hardware
(ie make Herc mods). But regardless
of the Herc mods, I need an API for
my BBS or Telix or pdptel (all ported
to MVS) to call to open, write, and
control a serial port.

OK. But don't muddle that with TCP/IP API calls. If you want to
control a device, then open that device, and then use the appropriate
control call. It is not a failing in TCP/IP that it doesn't do this
kind of thing.

Surely it is a failure in both TCP/IP and C90
to not cater for "control" commands for an
open device-connected socket and a
local device respectively?
Or perhaps the next layer that should be
added to TCP/IP is the telnet protocol,
and it is at that level that the IAC can be
sent to a device to do the equivalent of
ioctl()? ie instead of using arbitrary
characters like +++ it should be the
well-defined IAC? So we can stick with
a simple write() after all, no need for
an ioctl()? And ditto with fwrite after
an fopen("/dev/hd0") - we should be
careful, when writing, to double every
IAC character to prevent it from doing
a control of the device being written to?
Who should be doubling the IAC
characters? The application or fwrite()?
fopen("/dev/hd0,telnet", "r+b");
when manipulating a device, and somewhere
IAC N,8,1
into an actual ioctl() of the serial port to
set N,8,1.
fopen("/dev/hd0,telnet-clib", "r+b");
to get the C library to double the IAC
fopen("/dev/hd0,telnet-app", "r+b");
to allow the application program to take
care of doubling the IAC characters when
data is being written (in an application
that also issues control commands).
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
Or perhaps the next layer that should be
added to TCP/IP is the telnet protocol

Telnet is an application, not a protocol (Layer 7).

I'm not talking about telnet.exe I'm
talking about:

https://en.wikipedia.org/wiki/Telnet

"Telnet is a protocol used ..."


BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"I'm not talking about telnet.exe"

Neither am I.

Telnet is considered to be an application. What it does internally and how
it is implemented - who cares?

But when you talk about adding a telnet protocol to TCP/IP, youre muddling
what is properly at layer 7 (Application) with what belongs at layer 4 and
layer 3 (TCP and IP).

https://en.wikipedia.org/wiki/List_of_network_protocols_(OSI_model)

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
Or perhaps the next layer that should be
added to TCP/IP is the telnet protocol

Telnet is an application, not a protocol (Layer 7).

I'm not talking about telnet.exe I'm
https://en.wikipedia.org/wiki/Telnet
"Telnet is a protocol used ..."
BFN. Paul.

[Tony Harminc [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Post by Tony Harminc ***@gmail.com [hercules-os380]
via a GUI, but you probably want it in-band. You could do this in
several ways: one would he Hayes-style where you look for +++ or the
like and then accept commands; another would be to use the TCP
facility for having an out-of-band channel as part of the same TCP
connection (I believe telnet uses this to implement things like
Break), or of course you could have a separate TCP connection used
just for "control" calls, but one that's less user-friendly (GUI) and
more program-friendly.

The fact that you would break out into
a separate TCP connection for control
calls surely highlights a failure in the
TCP/IP protocol to distinguish between
a write and a control?

No, not at all. I suggested it as one possible approach of several.
The one I would use is the ability to have "out of band" data flow on
a TCP connection. Basically this allows you to write to a socket with
an option saying this data should not be queued behind whatever is
already there, but should "go to the front of the line". Normal data
flow

Post by ***@yahoo.com.au [hercules-os380]
It shouldn't be necessary to fudge the
data to look for "+++".

It isn't. For various reasons that is convenient for some users under
some circumstances. For instance if you have a dumb terminal connected
to a Hayes-style modem, the terminal doesn't have extra keys to
control the modem options, and the modem doesn't have buttons or a
control panel. So it makes perfect sense (and in fact was a patented
invention from which Hayes made a lot of money) to provide a timed
escape sequence to allow you to switch to talking to the modem itself
vs the far end by using in band data.

Post by ***@yahoo.com.au [hercules-os380]
Either that, or there should have been
yet another layer added on top of TCP/IP
that sends all information with a header
to say whether the data that follows is
a control, a write, a read or a sense.
And maybe a "control no-op", whatever
that is???

Post by Tony Harminc ***@gmail.com [hercules-os380]
Yes, but not to control things like a serial port. It controls various
aspect of socket processing. Sockets are not "devices" in the sense
you mean. Think of it this way: do you expect when you read/write a
UNIX file that there is a control call to tell the disk drive that
your file happens to be on to use a particular internal buffering
algorithm, to prefer performance to noise level, and so on? I think
not; it's outside the scope of an API set that deals with files.

But if I use fopen() to open "COM1", then yes,
I am in need of a further API to set the N,8,1.

Yes, but this has nothing, repeat nothing, to do with TCP/IP and its
APIs. If you open a device, you use (in the UNIX world, but it's
similar on others) an IOCTL call to read and set serial port options,
or lightbulb options or whatever. Here's an early hit I got from
Googling "ioctl"
http://www.tldp.org/LDP/lkmpg/2.4/html/x856.html
It's a pretty good short summary of the problem and how it's addressed
in Linux. Other OSs have very similar approaches.

You seem to remain confused. If your program uses a TCP socket, it is
communicating with another program also using a TCP socket at the
other end. It is not communicating with a terminal, and it is
completely out of scope of TCP/IP to talk to terminals. Of course you
can implement a device that has a screen and keyboard and talks TCP on
its network connection, but that's usually called a PC.

Post by ***@yahoo.com.au [hercules-os380]
I can imagine the need of the operating system
being able to open the disk drive /dev/hd0
and then setting the noise levels too. This
could potentially be done via fopen() too.

Yes, but it's not in the real world. IOCTL is what you want.

Post by ***@yahoo.com.au [hercules-os380]
You could argue that it is a failure in C90
to specify how to send a "control" to a
file opened via fopen(). Read and write
operations have been defined, and even
a "note position" and "seek" have been
defined - hell, double-defined in fact
(ie both fseek() and fsetpos()).
Perhaps C90 needs to be updated to
include something similar to ioctl(), if
they haven't already done so in C99
or C11.

Indeed. If you want all that kind of stuff in a programming language,
PL/I style. Others might prefer a library of functions. Oh, wait...

Post by ***@yahoo.com.au [hercules-os380]

Post by Tony Harminc ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
The next question is that I expect to
be able to manipulate a serial port
from MVS, if I have suitable hardware
(ie make Herc mods). But regardless
of the Herc mods, I need an API for
my BBS or Telix or pdptel (all ported
to MVS) to call to open, write, and
control a serial port.

OK. But don't muddle that with TCP/IP API calls. If you want to
control a device, then open that device, and then use the appropriate
control call. It is not a failing in TCP/IP that it doesn't do this
kind of thing.

Surely it is a failure in both TCP/IP and C90
to not cater for "control" commands for an
open device-connected socket and a
local device respectively?

I have no idea what you mean by "device-connected socket", and I
suspect you haven't either.

TCP does not connect your program to a terminal or any kind of
"device". You really need to understand this. TCP connects one socket
to another, or more loosely, one program to another. That's all it
does. There are control interfaces (IOCTL) that control aspects of
socket processing, but they have nothing to do with the underlying
hardware that TCP/IP is running on. A TCP/IP *implementation* may well
provide administrative interfaces, e.g. z/OS TCP/IP has APIs to allow
tracing, control various aspects of security, performance, routing,
etc. etc., but they are not for use by a normal application program,
and are not standardized.

As for failures in C90, well you know my opinion on that. While you're
getting them to add IOCTL to C90, why not get them to implement record
oriented files...?

Tony H.

[[e-mail] [hercules-os380]]

Post by Tony Harminc ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]

Post by Tony Harminc ***@gmail.com [hercules-os380]
OK. But don't muddle that with TCP/IP API calls. If you want to
control a device, then open that device, and then use the appropriate
control call. It is not a failing in TCP/IP that it doesn't do this
kind of thing.

Surely it is a failure in both TCP/IP and C90
to not cater for "control" commands for an
open device-connected socket and a
local device respectively?

I have no idea what you mean by "device-connected socket", and I
suspect you haven't either.

A small program running on a remote
site that connects to both a serial port
and a TCP/IP socket, and just passes
commands/data through.

That small program needs to have the
concept of data to be written to the
serial port, plus commands that need
to operate the serial port settings.

TCP/IP only provided the "data to be
written" API, not "control" concept.

Sure, I can make up my own protocol.

But it seems to me that TCP/IP (or
the next layer on top) should have
provided the equivalent of both
"write" and "ioctl", the same way
that Unix did and the same way
that IBM CCWs did.

Why leave the "control" concept out
from the TCP/IP protocol entirely?

And I'm not talking about controling
the socket itself, ie setting buffer
size or whatever. I'm talking about
operating some remote hardware
via TCP/IP instead of CCW. I expect
both TCP/IP and CCW to look the
same. There's only a minor difference.
TCP/IP is remote and CCW is local.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Post by Tony Harminc ***@gmail.com [hercules-os380]
I have no idea what you mean by "device-connected socket", and I
suspect you haven't either.

A small program running on a remote
site that connects to both a serial port
and a TCP/IP socket, and just passes
commands/data through.

A non-TCP/IP equivalent would be the
small program running on Computer B,
with one side opening up COM1 which
has a modem attached, and a USB
connection to Computer A. Computer
A can then send commands (open,
write and ioctl) down the USB line,
and Computer B will act on them.

The small program on Computer B
is not required to understand anything
about N,8,1, it just passes through
both control commands and writes.

The small program on Computer B
should be able to operate more than
just COM1, which is why it will need
to be able to handle the concept of
"open" too. And it just opens whatever
it was told to open. I think this creates
the need for some sort of standardized
protocol, and a layer above TCP/IP
should have included that too. So should
CCWs. Even if the standards are not
identical, they should be functionally
equivalent. The above scenario is over
USB cable, TCP/IP may be over
ethernet, and I don't know what sort
of cable CCWs go over to reach tape
drives etc, but it's probably pretty
thick.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Tony Harminc ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
It shouldn't be necessary to fudge the
data to look for "+++".

control panel. So it makes perfect sense (and in fact was a patented
invention from which Hayes made a lot of money) to provide a timed
escape sequence to allow you to switch to talking to the modem itself
vs the far end by using in band data.

I think this is a useful abstraction. Modems
should ideally have come with a protocol to
distinguish between commands for the modem,
and data to be transmitted remotely.

Without any pauses too.

Something like the Telnet IAC.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Tony Harminc ***@gmail.com [hercules-os380]
As for failures in C90, well you know my opinion on that. While you're
getting them to add IOCTL to C90, why not get them to implement record
oriented files...?

Hi Tony.

Can you elaborate on what exactly it is you
would like to see in the C standard regarding
record processing?

Do you want the ability to be able to declare
an internal buffer, like:

char buf[33000];

And then do an fopen with type=record and
then go:

size = fread()

and if you are processing a RECFM=F,LRECL=2000
file then you will get a return of 2000?

So that you can process any length RECFM=F
file instead of needing to know the exact size
of the record you are expecting, and not have
to pass the record length as a parameter either?

It is far more normal in MVS programming for
the internal record length to match the LRECL
of the file, and if you wish to change this, you
need to change both program and data.

And even if you do have such a thing in the
standard, how do you expect that to work
on Windows?

If you can't conceive how it will work on
Windows, then it's not really a language
standard, it's an MVS extension.

Or is it RECFM=V that you were hoping
they would add? If so, what specifically
were you hoping that to do, and again,
how do you see it working on Windows?

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

Well then you'd best start by learning the internals of VTAM.

You will need a VTAM application and corresponding major nodes (Ethernet
switched major node) to process TCPIP on MVS. You will also need a device
in hercules that emulates a 3172 external comms adapter...

Good luck.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Paul, just asking but you /have/ read

the Lion Book, haven't you?

which takes you immediately to a page for "Lions' Commentary on UNIX 6th
Edition, with Source Code".

https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_
6th_Edition,_with_Source_Code

And Googling for '"Lion Book" unix' gives me 'About 2,790 results' of
which at least the first page completely relevant.

I did not add "unix" to the google search
as I had no idea it was related to Unix.
You replied to a comment made about
Plan9, and I didn't even think to add
Plan9 to the search, because it didn't
occur to me that this might be a book
about Plan9 that I was expected to
have read or at least known about.
I actually guessed it was a culture
reference like "The tortoise and the
hare" or "The Young Ones", something
about the philosophy of some lion.
Regardless, I read the above link, and
no, I haven't read it, and no, I don't think
it would be wise for me to read it at this
point in time because it will pollute my
brain with prior art of Unix internals
and possibly lead me to the conclusion
that "this is thus impossible in MVS".
What I am instead interested in doing
is going from the MVS in particular,
and also possibly MSDOS perspective
and start implementing any functionality
that Unix has implemented, e.g. right
at the moment providing a TCP/IP
interface. If TCP/IP on Unix is currently
implemented with the use of fork(), and
that ends up being a show-stopper for
me, so be it. But for the moment I want
to assume that there is nothing stopping
this from being implemented on
MVS 3.8j, and I am willing to start learning
internals of MVS and even z/OS to try
to find the best API to call. You will note
that I already mentioned I don't like the
#include <sys/socket.h>
because it implies a directory structure
exists, something that is not mentioned
or required in C90. The first parameter
of fopen() can be anything at all, including
spaces as you see in CMS.
I remember a comment from a friend of
mine about 25 years ago, where he
commented that MVS was good for
some things, but if you wanted to
implement a web server, Unix was
far better. I didn't challenge this
statement, but I also didn't understand
it, even though I had some knowledge
of both systems. Just like I didn't know
what specifically, if anything, was
preventing MVS from handling character
mode terminals.
As I have mentioned before, I have a
goal penciled in to move all of my work
onto MVS, or a PDOS clone of it. ie
I want to do all my web browsing and
everything else from MVS. And run my
BBS on MVS too, which presumably
counts as a web server.
Maybe when I try and fail at this, I will
understand why my friend made his
comment about MVS. And maybe then
Lion's book will be useful to explain why
I failed to get MVS to totally replace
Unix and Windows.
Until then, I'm more interested in MVS
internals than Unix internals, because
it is MVS internals that I want to use
to give Unix and Windows functionality.
And in reverse, I would like Unix and
Windows to provide the same functionality
that MVS does. I can remember asking
a Unix expert on Solaris how I could get
an assembler listing for the Ada compiler
plus a formatted dump with registers
instead of the core file in case I needed to
debug at the assembler level, which I
considered to be a fundamental requirement.
He said there was no way to do that on Unix.
I do not know if there is some sort of
fundamental block in Unix that would
prevent such MVS functionality to be
added, but that's a question for another
day. I'm more interested in getting MVS
to replace Unix before turning around
and getting Unix to replace MVS.
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]
Well then you'd best start by learning the internals of VTAM.
You will need a VTAM application and
corresponding major nodes (Ethernet
switched major node) to process TCPIP

Ok, VTAM is still a mystery to me. I
guess it would be good if all my
C programs could in fact be presented
to the end user immediately, instead
of first being presented with the
Turnkey logo and then having to log
on to TSO.

ie you define a line-mode terminal to
Hercules and then as soon as you
telnet to it, you are presented with
the output of zcalc, which looks
like this:

C:\>zcalc
Welcome to the Calculator.Enter help at any stage to get instructions.

Builtin Functions Available

sin,cos,tan,log (base e),log10
asin,acos,atan,floor,ceil,sqrt
sinh,cosh,tanh,exp,fabs,cfact
power raising is indicated by **
e.g 2**3 will print 8.

Constants available

pi = 3.14159

Enter an expression
3+4
Calculated Value is 7.000000
Enter another expression
quit
Thank you for using the calculator

C:\>


Maybe I should work on something
like that first.

Can it be done generically, ie:

EXEC PGM=VTAMMAG,PARM='401 ZCALC'

which magically runs ZCALC pointing
to device 401?

Post by Joe Monk ***@gmail.com [hercules-os380]
on MVS. You will also need a device in
hercules that emulates a 3172 external
comms adapter...

Note that given that we don't actually
have the MVS source code, if this is
something that ideally requires MVS
modifications, it is acceptable to me
if we implement it a different way, and
do much of the implementation in
hardware instead (ie modify Hercules/380
instead).

As such, we could potentially have a
terminal type of 3216 which starts off
being the same as 3215, but it reacts
differently to incoming CCWs. I think
that might be cleaner than having a
hardware modification of a new
instruction like Jason Winter did that
magically does something as complex
as TCP/IP.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"Ok, VTAM is still a mystery to me. I
guess it would be good if all my
C programs could in fact be presented
to the end user immediately, instead
of first being presented with the
Turnkey logo and then having to log
on to TSO."

See you have a foreign concept there. With VTAM, you can have a terminal
that is not connected to any application. That terminal is said to be
connected to the network solicitor.

Then you type the LOGON command, followed by the name of the application
you wish to connect to.

You can define your applications within VTAM with shortcuts so that you
dont have to type LOGON APPLID(TSO), you can just type TSO.

Likewise, when you logoff from TSO, you are again connected to the network
solicitor.

Thats what VTAM does. It handles all of the comms processing so that an
application is not concerned with that aspect. An application just says
read or write ... VTAM takes care of the rest.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by Joe Monk ***@gmail.com [hercules-os380]
Well then you'd best start by learning the internals of VTAM.
You will need a VTAM application and
corresponding major nodes (Ethernet
switched major node) to process TCPIP

Ok, VTAM is still a mystery to me. I
guess it would be good if all my
C programs could in fact be presented
to the end user immediately, instead
of first being presented with the
Turnkey logo and then having to log
on to TSO.
ie you define a line-mode terminal to
Hercules and then as soon as you
telnet to it, you are presented with
the output of zcalc, which looks
C:\>zcalc
Welcome to the Calculator.Enter help at any stage to get instructions.
Builtin Functions Available
sin,cos,tan,log (base e),log10
asin,acos,atan,floor,ceil,sqrt
sinh,cosh,tanh,exp,fabs,cfact
power raising is indicated by **
e.g 2**3 will print 8.
Constants available
pi = 3.14159
Enter an expression
3+4
Calculated Value is 7.000000
Enter another expression
quit
Thank you for using the calculator
C:\>
Maybe I should work on something
like that first.
EXEC PGM=VTAMMAG,PARM='401 ZCALC'
which magically runs ZCALC pointing
to device 401?

Post by Joe Monk ***@gmail.com [hercules-os380]
on MVS. You will also need a device in
hercules that emulates a 3172 external
comms adapter...

Note that given that we don't actually
have the MVS source code, if this is
something that ideally requires MVS
modifications, it is acceptable to me
if we implement it a different way, and
do much of the implementation in
hardware instead (ie modify Hercules/380
instead).
As such, we could potentially have a
terminal type of 3216 which starts off
being the same as 3215, but it reacts
differently to incoming CCWs. I think
that might be cleaner than having a
hardware modification of a new
instruction like Jason Winter did that
magically does something as complex
as TCP/IP.
BFN. Paul.

[Bernd Oppolzer [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
What I am instead interested in doing
is going from the MVS in particular,
and also possibly MSDOS perspective
and start implementing any functionality
that Unix has implemented, e.g. right
at the moment providing a TCP/IP
interface. If TCP/IP on Unix is currently
implemented with the use of fork(), and
that ends up being a show-stopper for
me, so be it. But for the moment I want
to assume that there is nothing stopping
this from being implemented on
MVS 3.8j, and I am willing to start learning
internals of MVS and even z/OS to try
to find the best API to call. You will note
that I already mentioned I don't like the
#include <sys/socket.h>
because it implies a directory structure
exists, something that is not mentioned
or required in C90. The first parameter
of fopen() can be anything at all, including
spaces as you see in CMS.
I remember a comment from a friend of
mine about 25 years ago, where he
commented that MVS was good for
some things, but if you wanted to
implement a web server, Unix was
far better. I didn't challenge this
statement, but I also didn't understand
it, even though I had some knowledge
of both systems. Just like I didn't know
what specifically, if anything, was
preventing MVS from handling character
mode terminals.

FWIW: I wrote a routine some days ago for a customer of mine,
which allows PL/1 programs from the mainframe to call a Web service on a
remote machine (in fact it's an "Open Shift container"); this is a HTTP
PUT request.

The routine is written in IBM's C and runs on Unix and Windows, too.
It uses the same include files as Paul outlined above, for example

#include <sys/socket.h>

which are - of course - present on the mainframe, too.

The program does NOT run on z/OS UNIX, but on normal "classic"
z/OS; the include file <sys/socket.h> resides in a dataset, which
has .SYS appended to the "normal" file name where the other includes are
(something like SYS9.CEE.INCLUDE ... makes SYS9.CEE.INCLUDE.SYS).

Some caveats:

- the HTTP PUT request requires ASCII (or UTF-8), so the translation from
EBCDIC to ASCII has to be done by the C routine (that is: by me)

- the authorization requires a base64 encoded userid and password;
that, too, has to be done by the C routine (by me)

- the answer from the HTTP PUT request is in ASCII, too, and has to be
parsed (looking for HTTP 200 OK in the header, the text OK, for example,
being optionial)

- take care when reading the answer; don't read after the length specified
in the HTTP header, because: if you do, you will get lengthy timeouts
(30 seconds)

After some initial problems and experimentation, this now works very good
and very fast. We now think about putting the routine in a DB2 stored proc,
so that it can be called from everywhere (in fact, it is a - sort of -
database
request, but the database is not DB2; it resides on the Open Shift
platform;
but with this solution the applications can handle this LIKE a database
request).

Kind regards

Bernd

[Bernd Oppolzer [e-mail] [hercules-os380]]

Am 18.09.2017 um 12:21 schrieb Mark Morgan Lloyd

Post by Bernd Oppolzer ***@yahoo.com [hercules-os380]
FWIW: I wrote a routine some days ago for a customer of mine,
which allows PL/1 programs from the mainframe to call a Web service on a
remote machine (in fact it's an "Open Shift container"); this is a HTTP
PUT request.
The routine is written in IBM's C and runs on Unix and Windows, too.
It uses the same include files as Paul outlined above, for example
#include <sys/socket.h>
which are - of course - present on the mainframe, too.
The program does NOT run on z/OS UNIX, but on normal "classic"
z/OS; the include file <sys/socket.h> resides in a dataset, which
has .SYS appended to the "normal" file name where the other includes are
(something like SYS9.CEE.INCLUDE ... makes SYS9.CEE.INCLUDE.SYS).

Which of course raises an interesting question: if the <> notation tells
the preprocessor to do something system-specific like searching a path,
isn't this where all filename mangling and special measures should be
hidden?

IIRC, IBM C (z/OS) searches two DD-Names, SYSLIB and USERLIB.

SYSLIB is used with include files that are coded like this

#include <file.h>

and USERLIB like this

#include "file.h"

I guess, on Unix and Windows, there is a difference between the two
notations, too;
in the most simple way, the current directory is search first, when
using the "..." notation,
which is not done, when using the <...> notation. The rest of the search
is done using
the INCLUDE environment variable.

On the mainframe, the search is done using the concatenation of SYSLIB
and USERLIB.

Both (or all three) platforms have in common (IMHO), that paths
specified on the
#include (like in <sys/socket.h>) are appended to the directories (or
file names)
before trying to open the include file. This, of course, has to be done
in a way
which is specific to the platform.

This always seemed total intuitive to me and perfectly understandable.

HTH, kind regards

Bernd


.

[[e-mail] [hercules-os380]]

Post by Bernd Oppolzer ***@yahoo.com [hercules-os380]
The routine is written in IBM's C and runs on Unix and Windows, too.
It uses the same include files as Paul outlined above, for example
#include <sys/socket.h>
which are - of course - present on the mainframe, too.
IIRC, IBM C (z/OS) searches two DD-Names, SYSLIB and USERLIB.
SYSLIB is used with include files that are coded like this
#include <file.h>
(something like SYS9.CEE.INCLUDE ... makes SYS9.CEE.INCLUDE.SYS).

That's some pretty fancy footwork. Look
for a dataset in the SYSLIB concatenation
and add "SYS" to the end of it, and then
look for the member in that.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Tony Harminc ***@gmail.com [hercules-os380]
network oriented. Open source under licensing conditions that are
probably acceptable even to Paul,

No, anything that doesn't have an
explicit "released to the public domain"
with no caveats is dead in the water
to me, at least in the long term.

While ever people balk at adding
such a line to their code, it's clear
to me that they wish to hold
something back, which in turn
makes me balk.

While I never really expected that
I would really be sued by someone
with some sort of open source
license, I did think that in principle
I should make plans assuming that
was the case.

So the TK3SU1 debacle came as
somewhat of a shock to me, with
takedown notices and copyright law
being thrown at me and the threat
of being taken to court.

I think there was a case of the people
who added "Ada" to GCC - GNAT
being threatened with legal action too.
Personally I didn't think they had
violated the 734 conditions in the
Gnu Virus License, from my
understanding, but only a court could
have decided that, and the Ada people
ended up just caving in, and the
GNU jackasses bragged about that.

So yes, when I go to court, and face a
judge who doesn't actually know
anything about programming, I want to
be in a position to say "Your honor, take
a look at this line that says 'released to
the public domain'. Case closed.". I
don't think my opponent will have a leg
to stand on. I can't be 100% sure of
that, but it's the best I can do.

Instead, if the judge looks at a line that
says "copyright fred flinstone", he will
look at me and say this is a very clear
copyright statement. This code is not
yours. What makes you think you have
a right to take it as your own?

And the onus is on me to prove my
innocence.

I have absolutely no faith in the justice
system. In Australia, to reduce costs,
the government made political
advertising illegal. The courts
overturned that as unconstitutional.
They simply make up whatever the
hell they want. There's nothing in
our constitution that says that is
illegal, and we do not have a Bill
of Rights either.

I know of someone who got charged
under a *computer game* law for writing
fictional text stories about underage
sex.

Other people have been charged for
criticizing muslims and part-aboriginals.

Note that the government also bans
various people from entering the
country because they are Holocaust
deniers or whatever.

I would actually offer my services to
read out whatever the hell some
foreigner wants to say in Australia
but can't because he's been banned
entry.

I have no idea what this is meant to
achieve when I could simply go to
the person in question's website.

And the government has censored
X-rated movies for as long as I've
been alive, all completely bypassed
with the internet, with the devasting
result of, well, nothing actually as it
turns out. What a surprise! All those
human rights violations for nothing.

In practice I personally can write
whatever I want. No-one in Australia
could care less what I write, including
the government. I've even written an
open letter to the Chinese government
asking them to nuke Canberra:

http://antisubjugator.blogspot.com.au/2007/01/nuke-canberra.html

Ok, that particular post at least got
some Australians to comment that
I was an idiot, but normally nothing
I post is of any interest to anyone.
Although that is normal:

https://despair.com/products/blogging

Never before have so many people
with so little to say said so much to
so few.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Again, not relevant. You're asking about making something
unix-compatible, not making it into a generic C platform.

No, that is not correct. I am just leery
about deviating from Unix when I have
been explicitly told that those who
deviate from Unix will always end up
with something worse (like Chavez

But you did say "reimplementing unix".

Only in the subject line, and only as a
summary of *someone else's* line:

"those who do not understand Unix
are condemned to reimplement it
badly".

I don't want to be one of those people
who didn't understand Unix so went off
on some half-cocked alternative only
to find out after many years that
absolutely everything I could possibly
want was already in Unix, and has
been for many decades.

The *potentially* half-cocked alternative
I am currently pursuing is PDOS/370
and z/Paulix, where everything switches
to the MVS API and EBCDIC.

You didn't say "a ground up
review of all design decisions".

Well maybe I should have.

I am simultaneously exploring PDOS/386
and PDOS/370 and wondering where Unix
slots into the above. Do I need a
PDOS-UNIX/370 or should it just be
UNIX/370? Or should it be as it is now,
just PDOS/370?

I am basically somewhat confused about
operating systems, but what I do know is
that I am starting with C90 and trying to
get C90 applications to work on "all the
above operating systems, even though
I don't actually know their names yet".

The bottom line is that unix, C, POSIX etc. (and their equivalents on
the Windows side) comprise a useful set of approximately layered
standards, which have allowed communities like the contributors to
Sourceforge, Github and so on to thrive. Move away from the standards
and you'll need to get everybody there to check their code and build
processes for compatibility, and my suspicion is that 50% of projects
would need work.

I suspect the figure is more like 98% of
projects, given that one of the target
environments I expect to be covered
is MVS 3.8j.

Every open source project should provide
*at least* 2 executables - Windows and
MVS. I don't particularly expect to see a
"Unix" executable because there is
more-or-less no such thing because of
all the different CPUs that could mean.

And that's something I'm exploring in
itself - why isn't Windows, or at least
MSDOS, running on S/370 and why
isn't MVS running on 80386? Why does
Unix run on so many different CPUs,
but Windows and MVS are unable to
match that? Did someone make a
decision at some point that tied MVS
and Windows down to their respective
CPUs? What was that specific decision?
Can that decision be reversed? If not,
what specific line of code cannot be
reversed out for eternity?

I think you said a day or so ago that one of your criticisms of fork()
is that it has to copy the memory state of the parent to make it
available as the starting state of the child.

My criticism is that it doesn't exist on
MVS or MSDOS already, and I don't
believe that MVS or MSDOS are the
ones who are deficient because they
didn't, and possibly even can't, implement
that concept.

Then, this concept is extremely low-level,
an application telling the operating system
that it wants to do an extremely complicated
operation of duplicating a load module and
all its data.

This is far, far removed from any legitimate
business application. GCC is a text
processing program that reads in a bunch
of text files and outputs a single text file.
At absolutely no point in this text processing
logic should a programmer have decided
"right, now what I really need is not the
next line of text from a text file, but instead
to have the underlying executable cloned,
plus the data copied too".

When the actual business logic that was
required at this point was "call a function
or load module or whatever that takes the
now-preprocessed file and convert it into
assembler code. (ie invoke cc1 now that
cpp has finished - or similar).

Whether you do cc1() or system("cc1")
or spawn("cc1") can be debated, and I
think by default it should be cc1() with
non-default options available so that on
*some systems* you can create separate
load modules. Note that it is beyond C90
to ensure that system("cc1") will be useful,
so cc1() is required by default to be
C90-compliant.

If you really don't like the unix design philosophy then why are you
using it as a groundplan at all?

At least nominally, I neither like nor
dislike Unix. Especially a Unix flavor
that says you must never call fork(),
but spawn() is available. I'm still
trying to understand things.

And from a C90 perspective (which
is where I still am, I haven't yet
reached directory traversal algorithms
in PDPCLIB - and nor will I, because
it is not in C90 - but maybe I will at
some point create a new library which
will have functions like opendir() which
work on *all* of MVS, Windows and
Unix.

And it's not just Unix that I have issues
with. I don't like Windows requiring DLLs.
I want stand-alone executables in
PDOS/386 which means I will probably
be sticking with MSDOS-like executables
rather than Windows-like executables.

This will complicate plans to provide a
competitor to Windows.

Similarly I don't want any of my MVS
programs to call LE or other random
load modules, e.g. a reentrant
PDPCLIB module that all of my C
programs can share. I instead want
static linking.

And as Peppe reported in his experience
of Linux, the changes to shared libraries
etc cause Linux to be incompatible with
itself after a few months.

Basically DLLs suck, and that's why "DLL
hell" exists and is even documented:

https://en.wikipedia.org/wiki/DLL_Hell

So basically you can say that so far I
have penciled in two design decisions
already:

1. Standalone modules, no DLLs
2. fork() is not available.

Those design decisions are going to
be applied to:

1. PDOS/386
2. PDOS/370
3. z/Paulix or maybe even just Paulix if
it can run on a 386 processor too. This is
still unclear to me. I haven't seen anyone
say Linux/SPARC or Linux/386 so I'm
not sure why people say z/Linux.

Note that my design decisions above,
to not use shared libraries, and not
provide or use fork(), mean that I am
in fact deviating from proper Unix, so
that is why I am a bit nervous when I
have been told "those who do not
understand Unix are condemened
to reimplement it badly". ie I guess
there is an implication there that I
don't understand shared libraries,
so I have condemned myself.

Instead I am happy for MVS-style
SVCs and also MVS-style executing
functions linked from the CVT. If
MVS internally converts those
functions into something resembling
DLLs I don't care. But I don't want to
be exposed to the concept of DLLs
myself - anywhere in my executable.
No DLL-processing crap linked in.
CVT is fine though.

I hope this makes some sort of sense,
I'm only vaguely aware of what I am
really trying to achieve. Such as the
recent plan to create a Telix 3.12
clone. That is not something that I
started planning 10 years ago as part
of some elaborate plan. It's just
haphazardly seeing (what I consider
to be) holes and trying to fix them.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
At least nominally, I neither like nor
dislike Unix.

I also neither like nor dislike records.
To me that is a very minor implementation
detail of no interest to the programmer.

When I was an atheist, a Christian asked
me what made me "be good" when I didn't
have a god to answer to.

I explained that to me whether there is a
god or not is just a minor technical detail.
I had just made a guess that there wasn't.
I don't even know if my guess was right.

Regardless, even if I was absolutely 100%
sure I had guessed correctly, and there was
no god to answer to, that doesn't mean I
suddenly say "woo hoo. I can go and stick
a knife in a dog and listen to it yelp in pain -
I've always wanted to do that!".

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I also neither like nor dislike records.
To me that is a very minor implementation
detail of no interest to the programmer.

Well, I should clarify that. It *should* be
of no interest to a C90-programmer or
an ISO Pascal programmer when they're
writing their actual code.

Of course programmers are expected
to know how to do a chmod on Unix
or specify DCB information on MVS.
But that happens (or SHOULD happen)
outside the actual application, in my
opinion, if you don't want to be one of
the 98+% of projects on github that do
not ship with an MVS XMIT and in
fact, don't even compile on GCCMVS.

BFN. Paul.