Communication Between MVS in Hercules && Herc's Linux, etc. Host: How?

Discussion:

Communication Between MVS in Hercules && Herc's Linux, etc. Host: How?

time2ipl

2008-06-30 01:17:43 UTC

Hi, all -

I've been trying to figure out how to get MVS 3.8 (the same one
everyone else seems to be using) to "talk to" the Linux host that
Hercules is running on.

Networking / TCP/IP support isn't the problem. What I'm in need of is
either an application (preferably) or an API (at a minimum) that will
let me communicate across either a CTC adapter or LCS adapter to the
host that Hercules is running on. What I'm missing, is a program that
can talk to the outside world through that interface.

Just as a side note: I'm not yet familiar with either CTC or LCS
adapters. I've done a lot of communications programming, but the bulk
of the work I've done with mainframes has been at the protocol and
application levels.

Is there, currently, a working TCP/IP protocol stack for MVS 3.8; and,
if there is, could someone point me to it? And to whatever apps there
are that utilize it?

After my first web search, this seemed like it'd be a pretty easy nut
to crack; I found numerous references to "Jason Winter", his FTP
server, and "the jcc compiler". Unfortunately, all of them seem to
have vanished; apparently thanks to (at least in part) a company
called "Dignus Systems".

If TCP/IP isn't an option, can someone point me to where I could begin
trying to cook up an alternate way to "talk to" the MVS system? I've
seen "netcat" work, reliably, so I know it's possible to get data from
point A to point B. I'm just not clear on how... Nor am I clear how
the CTC and/or LCS adapters play into the whole picture. But,
hopefully, someone - or several someones - can help me with that...

Thanks in advance,

Larry

Peter

2008-06-30 02:24:02 UTC

Post by time2ipl
I'm not yet familiar with either CTC or LCS
adapters. I've done a lot of communications programming, but the bulk
of the work I've done with mainframes has been at the protocol and
application levels.

CTC is the easiest, although the MVS side will have to have an ATTN
handler.

The protocol can beexceptionally simple.

One side issues, say, a WRITE-type command to the CTC.

The other side is immediately interrupted (I/O 'rupt).

The other side immediately issues a SENSE to the CTC, thereby giving
it, say, the WRITE-type command code as a sense byte.

If a WRITE, then it issues a READ.

If a READ, then it issues a WRITE.

Encoded within the command may be a block size, or other indication
of the I/O type.

The two sides continue until they mutually agree that all relevant
data has been exchanged, whereupon the two sides go to sleep, until
the next time.

time2ipl

2008-06-30 04:38:15 UTC

Peter,

Thanks for getting back to me. That makes sense; I guess I wasn't too
far off in what I had surmised about the CTC adapter from reading
about it.

Any chance you might have a sample kicking around that installs an
ATTN handler and writes back to the CTC adapter whatever it received
(i.e., the equivalent of a TCP 'echo' server?) I don't have the
foggiest as to how to open the (CTC) device, issue some sort of
blocking read on the device, etc.; if someone had a simple sample that
I could reverse engineer, ...

Is there any facility or application in MVS that already communicates
via the CTC adapter?

Thanks for your help,

Larry

Post by Peter

Post by time2ipl
I'm not yet familiar with either CTC or LCS
adapters. I've done a lot of communications programming, but the bulk
of the work I've done with mainframes has been at the protocol and
application levels.

CTC is the easiest, although the MVS side will have to have an ATTN
handler.
The protocol can beexceptionally simple.
One side issues, say, a WRITE-type command to the CTC.
The other side is immediately interrupted (I/O 'rupt).
The other side immediately issues a SENSE to the CTC, thereby giving
it, say, the WRITE-type command code as a sense byte.
If a WRITE, then it issues a READ.
If a READ, then it issues a WRITE.
Encoded within the command may be a block size, or other indication
of the I/O type.
The two sides continue until they mutually agree that all relevant
data has been exchanged, whereupon the two sides go to sleep, until
the next time.

Peter

2008-06-30 06:11:39 UTC

Post by time2ipl
Any chance you might have a sample kicking around that installs an
ATTN handler and writes back to the CTC adapter whatever it received
(i.e., the equivalent of a TCP 'echo' server?) I don't have the
foggiest as to how to open the (CTC) device, issue some sort of
blocking read on the device, etc.; if someone had a simple sample that
I could reverse engineer, ...

There is a spare slot in the Attention Table which is not used by
IBM. Others are reserved for OLTEP, JES, IMS, Graphics, etcetera.

Basically, you store the address of an IOSB and an SRB there, and
Basic IOS will use the IOSB to do a STARTIO using that IOSB to read
the sense bytes.

It has to be done at this point, otherwise the sense data will be
lost, as an unsolicited 'rupt, such as an ATTN, would otherwise be
cleared by IOS, and any resulting sense data would be thrown away.

The ATTN routine then SCHEDULEs the IOSB into the responder's address
space where he examines the sense data and then proceeds.

There are several unique paths through IOS for ATTN handling, such as:

1) Ignore,

2) Immediately redrive I/O on that same subchannel,

3) Initiate I/O on another subchannel,

etcetera, all driven by return vectors ... BR R14, B 4(0,R14), B 8
(0,R14), for example.

These options are there for JES and IMS, but can be used by others.

The ATTN handler, out of necessity, must operate disabled, and while
it is running it has the highest priority.

Post by time2ipl
Is there any facility or application in MVS that already communicates
via the CTC adapter?

JES3 uses CTC to perform intersystem communication.

Also IMS.

The JES3 code could be a good model.

The IBM code may be difficult to find.

The basic strategy is the two sides agree on what the extended
command codes mean to them ... that is, the modifier bits to the
basic READ and WRITE commands.

These otherwise ignored bits usually encode a block size, or a data
block type (which itself can imply a block size).

The basic SENSE command has its usual meaning.

Peter

2008-06-30 06:18:15 UTC

Post by Peter
The IBM code may be difficult to find.

The IMS code, of course.

I found it, after a lot of searching, and it was about as complicated
as the JES3 code.

Harold Grovesteen

2008-06-30 17:54:41 UTC

With all of these various mechanisms, do not forget you need something
on the other side that understands the connection. Hercules has a CTC
over IP implementation that would allow the Linux (or other) end to be a
TCP/IP connection. Numerous ways to implement that: everything from C
to Java and many other alternatives in between. A CTCAM
(Channel-to-channel Access Methed) might be useful on the MVS side.
Solve this problem once on the MVS side that lets others levarage it.

Harold Grovesteen

Post by time2ipl
Peter,
Thanks for getting back to me. That makes sense; I guess I wasn't too
far off in what I had surmised about the CTC adapter from reading
about it.
Any chance you might have a sample kicking around that installs an
ATTN handler and writes back to the CTC adapter whatever it received
(i.e., the equivalent of a TCP 'echo' server?) I don't have the
foggiest as to how to open the (CTC) device, issue some sort of
blocking read on the device, etc.; if someone had a simple sample that
I could reverse engineer, ...
Is there any facility or application in MVS that already communicates
via the CTC adapter?
Thanks for your help,
Larry

Dave Wade

2008-06-30 12:10:07 UTC

Larry,

There has never been a real functioning TCP/IP stack in MVS3.8J. What
Jason did was to steal op code "75" and use it to pass TCP/IP socket
calls in and out of MVS. So there was basically a DLL that was loaded
with Hercules that handled OpCode 75 and mapped it onto host socket
calls. allowing MVS to use the IP stack on the PC. Unfortunatly he
copyrighted the code, and I can't find the redistribution restrictions
so I can't send you a copy. (In general I think you were/are NOT allowed
to re-distribute most of Jason's stuff)

CTC and LCS devices work at a lower level and so require a good
knowledge of IP (and MAC I think for LCS) so I think using them would
require a complete network stack in MVS3.8J, or would require extensive
mods to Hercules. Depending on how I wanted to talk I think I might do:-

1) Hi-jack a 3270 session in the same way that ind$file does.
2) Use sockets to the reader/printer => this is what NETCAT does
3) Use the bi-sync to IP line driver like the various RJE programs do.
This could also be used in a similar way to "1" to hack 3270 code.

I might also use the DIAG8 code in Hercules to pass command results back
and forth in combination with the above...
So little time so much to do....

Dave

Post by time2ipl
Hi, all -
I've been trying to figure out how to get MVS 3.8 (the same one
everyone else seems to be using) to "talk to" the Linux host that
Hercules is running on.
Networking / TCP/IP support isn't the problem. What I'm in need of is
either an application (preferably) or an API (at a minimum) that will
let me communicate across either a CTC adapter or LCS adapter to the
host that Hercules is running on. What I'm missing, is a program that
can talk to the outside world through that interface.
Just as a side note: I'm not yet familiar with either CTC or LCS
adapters. I've done a lot of communications programming, but the bulk
of the work I've done with mainframes has been at the protocol and
application levels.
Is there, currently, a working TCP/IP protocol stack for MVS 3.8; and,
if there is, could someone point me to it? And to whatever apps there
are that utilize it?
After my first web search, this seemed like it'd be a pretty easy nut
to crack; I found numerous references to "Jason Winter", his FTP
server, and "the jcc compiler". Unfortunately, all of them seem to
have vanished; apparently thanks to (at least in part) a company
called "Dignus Systems".
If TCP/IP isn't an option, can someone point me to where I could begin
trying to cook up an alternate way to "talk to" the MVS system? I've
seen "netcat" work, reliably, so I know it's possible to get data from
point A to point B. I'm just not clear on how... Nor am I clear how
the CTC and/or LCS adapters play into the whole picture. But,
hopefully, someone - or several someones - can help me with that...
Thanks in advance,
Larry

kerravon86

2008-06-30 12:58:39 UTC

Post by Dave Wade
There has never been a real functioning TCP/IP stack in MVS3.8J. What
Jason did was to steal op code "75" and use it to pass TCP/IP

socket

Post by Dave Wade
calls in and out of MVS. So there was basically a DLL that was

loaded

Post by Dave Wade
with Hercules that handled OpCode 75 and mapped it onto host socket
calls.

Since I already have a custom version of Hercules, I might
be able to hook this in without a DLL. I know where op
codes are defined in Hercules. If there's a use for this,
what is required? Whenever an MVS app executes op code
75, what should happen?

And where or what is the MVS app anyway?

I'm not familiar with TCP/IP. Or Rexx! Still waiting for
your reply on that Rexx code BTW.

BFN. Paul.

time2ipl

2008-06-30 16:59:17 UTC

Thanks, Peter and Dave, for your time and efforts.

Peter, the main problem I would have trying to use JES3 or IMS DB/DC
as models - assuming that I was able to get access to the source code
for either or both of them, I'm not sure how, exactly, you were able
to - is that I'm not familiar with JES3 from an end-user's standpoint
(we never used JES3, just JES2). I see that it's available through
the CBT tape site, though; might be worth taking the time to install
it and learn it. As far as IMS goes, the last time I worked with it
to any extent was c. 1990, with IMS/DB, which our CICS system used as
its DBMS. I did a few searches after I read your reply, and I can see
that there's a whole lot more to it than I was aware of...

Post by Dave Wade
There has never been a real functioning TCP/IP stack in MVS3.8J. What
Jason did was to steal op code "75" and use it to pass TCP/IP socket
calls in and out of MVS. So there was basically a DLL that was loaded
with Hercules that handled OpCode 75 and mapped it onto host socket
calls. allowing MVS to use the IP stack on the PC.

Dave, thanks; that makes a whole lot more sense now. So, much of what
was done, was done at the Hercules level. That's promising...

Post by Dave Wade
Unfortunatly he copyrighted the code, and I can't find the
redistribution restrictions so I can't send you a copy. (In
general I think you were/are NOT allowed to re-distribute most of
Jason's stuff)
From what I've been able to gather, Jason's code has been available

under a variety of licensing schemes. According to this page, his
TCP/IP package was "please send cash-ware"
(http://www.cbttape.org/~jmorrison/mvs38j-ip/index.html); it had been
available at http://tech.groups.yahoo.com/group/H390-MVS/files/
(m38tcp.tar.bz2, Jason Winter's TCP/IP instruction) but has apparently
been taken down as the link to it is "dead"; with respect to "the jcc
compiler", this message intimates that he's using a "user class"
(i.e., student, hobbyist, professional, etc.) type licensing scheme:
http://osdir.com/ml/emulators.turnkey-mvs/2004-11/msg00039.html. So,
I think "what license is ____ covered under?" is, at least in part, a
function of time...

I've also found "the Xinu stack", which I'm assuming does something
similar (right?). Now, that I have found available for download.
It's not clear to me how far along it is, though - whether it's "ready
for prime-time", or still somewhere short of that...

Post by Dave Wade
CTC and LCS devices work at a lower level and so require a good
knowledge of IP (and MAC I think for LCS) so I think using them would
require a complete network stack in MVS3.8J, or would require extensive
mods to Hercules. Depending on how I wanted to talk I think I might do:-
1) Hi-jack a 3270 session in the same way that ind$file does.
2) Use sockets to the reader/printer => this is what NETCAT does
3) Use the bi-sync to IP line driver like the various RJE programs do.
This could also be used in a similar way to "1" to hack 3270 code.

The IP knowledge part isn't a problem; at this point, it'd be overkill
to write a complete TCP/IP network stack just to pass data from MVS to
whatever machine Hercules is running on; I'm still in the "proof of
concept" phase here.

"Borrowing" a 3270 session is a good idea; it'd be "just like the old
days"...

The netcat solution has potential. It's possible to create a printer
that's only servicing jobs of a certain class, right? Or somehow
otherwise sort-of kind-of "protect" it from output from other apps.
Right? Is it possible to do the same thing with a punch?

The third potential solution you've got listed - the bi-sync to IP
line driver - are you thinking about just using the line, or
full-blown BTAM? If it's possible to get a bisync line up and running
without too much of a hassle, that would seem to be the cleanest way
to do this...

I went looking for sample / example code, wasn't able to find any -
you wouldn't happen to have any, would you? Also, what would the
entry in the Hercules conf file look like for such a beast (bisync line)?

Post by Dave Wade
I might also use the DIAG8 code in Hercules to pass command results back
and forth in combination with the above...

Right. Actually, assuming I had a pathway into and out of MVS, it
should be possible to craft something which results in said data
ending up on the *NIX TCP/IP stack in a number of different ways. I
was thinking more along the lines of "virtual network adapter", but if
using the DIAG8 code is a clean way to get the same net effect, that's
fine with me.

Post by Dave Wade
So little time so much to do....

Yeah... I hear that...

Speaking of which, thanks very much again for yours - and Peter's - to
date. I may just end up crafting something usable yet; if I do, it'll
most definitely be free for the asking. This seems to be a pretty
common problem that's been a pain in the, uh, neck, for a while...

- Larry

Post by Dave Wade

Post by time2ipl
Hi, all -
I've been trying to figure out how to get MVS 3.8 (the same one
everyone else seems to be using) to "talk to" the Linux host that
Hercules is running on.
Networking / TCP/IP support isn't the problem. What I'm in need of is
either an application (preferably) or an API (at a minimum) that will
let me communicate across either a CTC adapter or LCS adapter to the
host that Hercules is running on. What I'm missing, is a program that
can talk to the outside world through that interface.
Just as a side note: I'm not yet familiar with either CTC or LCS
adapters. I've done a lot of communications programming, but the bulk
of the work I've done with mainframes has been at the protocol and
application levels.
Is there, currently, a working TCP/IP protocol stack for MVS 3.8; and,
if there is, could someone point me to it? And to whatever apps there
are that utilize it?
After my first web search, this seemed like it'd be a pretty easy nut
to crack; I found numerous references to "Jason Winter", his FTP
server, and "the jcc compiler". Unfortunately, all of them seem to
have vanished; apparently thanks to (at least in part) a company
called "Dignus Systems".
If TCP/IP isn't an option, can someone point me to where I could begin
trying to cook up an alternate way to "talk to" the MVS system? I've
seen "netcat" work, reliably, so I know it's possible to get data from
point A to point B. I'm just not clear on how... Nor am I clear how
the CTC and/or LCS adapters play into the whole picture. But,
hopefully, someone - or several someones - can help me with that...
Thanks in advance,
Larry

Peter

2008-06-30 20:14:16 UTC

Post by time2ipl
Peter, the main problem I would have trying to use JES3 or IMS DB/DC
as models - assuming that I was able to get access to the source code
for either or both of them, I'm not sure how, exactly, you were able
to - is that I'm not familiar with JES3 from an end-user's standpoint
(we never used JES3, just JES2). I see that it's available through
the CBT tape site, though; might be worth taking the time to install
it and learn it.

The CTC code is in one module.

The initialization code is likely in another.

Neither JES nor IMS do an OPEN. They just plug in the values which
are necessary for IOS to recognize the ATTN handler as theirs, and
then SCHEDULE the SRB into their address space.

That is the difficult code ... the "responder".

The code for the "initiator" (not the IEF one) is like any EXCP
operation to a device which may or may not have been OPENed, but at
least has control blocks which represent themselves as if they were
the result of an Open. The DEB in SP=253 is probably the only
difficult part.

In earlier lifetimes, dummy devices would be SYSGENed, and then
zapped to the required configuration. A dummy UCB is large enough to
support the CTC function. Heck, I suppose UNIT-CTC could also be
used, but this may confuse someone, possibly O/C/EOV.

The "responder" code does the sense, then SCHEDULEs the SRB into the
target address space (that is all it CAN do, as it is running
completely disabled at this point), then the SRB code, once it gets
into its target address space, calls the Exit Effector Stage II to
schedule an IRB, which allows most of the responder code to be in
task mode. The parameter passed to the IRB routine would be the
result of the SENSE ... the command code issued by the "initiator".
As most of the "responder" code is running in task mode, it can issue
SVCs, including EXCP to the CTC, and do anything else which may be
required.

A file transfer program would be an easy example ... read a block
from a source dataset, reformat it for the CTC device, then issue an
EXCP to the CTC and WAIT for the CTC to respond and to have swallowed
the data. Then repeat.

Possibly the only unique feature would be a WRITE-EOF command, which
could be a WRITE command with a zero length code, just as with real
DASD.

Jim Morrison

2008-06-30 20:35:19 UTC

--- In H390-MVS-***@public.gmane.org, "time2ipl" <***@...> wrote:
[Dave Wade G4UGM wrote:]

Post by time2ipl

Post by Dave Wade
There has never been a real functioning TCP/IP stack in MVS3.8J.

Check out the IP stack in CBT tape file 571 (archived in a huge
collection archive member somewhere). IIRC the base stack,
UDP protocol, and ICMP protocol were working at a proof of concept
level as archived. The base for the implementation was Dr. Comer's
Xinu design and implementation, ported to MVS38j (C and assembler).
The TCP protocol implementation was never ported, altho Dr. Comer
did provide one. See also the URL below for further details.

Post by time2ipl
(http://www.cbttape.org/~jmorrison/mvs38j-ip/index.html)
I've also found "the Xinu stack", which I'm assuming does something
similar (right?). Now, that I have found available for download.
It's not clear to me how far along it is, though - whether it's "ready
for prime-time", or still somewhere short of that...

The Xinu source you probably found is quite PC-specific, but it's
what I used to start the MVS38j IP stack I did. If you pursue it,
you will definitely want Dr. Comer's books for documentation. The
I/O portions of the Xinu implementation required extensive mods,
and IIRC I ended up with EXCP I/O against an open DCB and an I/O
appendage to redrive the I/O.

kerravon86

2008-06-30 22:24:35 UTC

Post by Jim Morrison
Check out the IP stack in CBT tape file 571 (archived in a huge
collection archive member somewhere). IIRC the base stack,
UDP protocol, and ICMP protocol were working at a proof of concept
level as archived. The base for the implementation was Dr. Comer's
Xinu design and implementation, ported to MVS38j (C and assembler).
The TCP protocol implementation was never ported, altho Dr. Comer
did provide one. See also the URL below for further details.

Post by time2ipl
(http://www.cbttape.org/~jmorrison/mvs38j-ip/index.html)

This link hasn't been updated for 5 years. Is that
correct that no work has been done for 5 years?
It pointed to a Yahoo group that doesn't seem to
exist, and an ftp site which also doesn't exist.

It mentioned that only C bindings were available.

Can someone tell me what C function(s) are required?

I'm trying to guess how the opcode 75 was implemented.
Depending on the parameters that were passed to the
C function, the C function could have bundled up those
parameters, pointed a register to them, then executed
the op code. The op code could then have demangled them
and called some native function by the same name.

Seems straightforward.

Although I think I would make the op code designed to
operate on a stack of registers for all the different
parameters required. And just save those registers
as normal before executing the instruction.

It would mean you couldn't port the executables
outside Hercules, but source code compatibility would
remain.

Does MVS have a macro to do TCP/IP? I could hide the
stuff in the macro, but the executable would still
not be portable without an SVC.

BFN. Paul.

Phil Dickinson

2008-06-30 22:44:52 UTC

Hi Paul,

If you are thinking of implementing a method to access the underlying
tcp/ip from a hercules host (like MVS 3.8J), can I suggest you have a
look at the IUCV method as used by Music/sp?

Check out the IUCV doco on this site......

http://www.geocities.com/sim390/techinfo.htm

This is very similar to what you are trying to achieve via an
instruction.... the benefit of doing it this way is that Music/SP
would then be able to access tcp/ip when running on Hercules.

I think (but I'm not sure) that making MVS 3.8J work with IUCV would
be just as easy (or hard) as doing so with a new instruction.

But I might be wrong.

Phil

Post by kerravon86

Post by Jim Morrison
Check out the IP stack in CBT tape file 571 (archived in a huge
collection archive member somewhere). IIRC the base stack,
UDP protocol, and ICMP protocol were working at a proof of concept
level as archived. The base for the implementation was Dr. Comer's
Xinu design and implementation, ported to MVS38j (C and assembler).
The TCP protocol implementation was never ported, altho Dr. Comer
did provide one. See also the URL below for further details.

Post by time2ipl
(http://www.cbttape.org/~jmorrison/mvs38j-ip/index.html)

This link hasn't been updated for 5 years. Is that
correct that no work has been done for 5 years?
It pointed to a Yahoo group that doesn't seem to
exist, and an ftp site which also doesn't exist.
It mentioned that only C bindings were available.
Can someone tell me what C function(s) are required?
I'm trying to guess how the opcode 75 was implemented.
Depending on the parameters that were passed to the
C function, the C function could have bundled up those
parameters, pointed a register to them, then executed
the op code. The op code could then have demangled them
and called some native function by the same name.
Seems straightforward.
Although I think I would make the op code designed to
operate on a stack of registers for all the different
parameters required. And just save those registers
as normal before executing the instruction.
It would mean you couldn't port the executables
outside Hercules, but source code compatibility would
remain.
Does MVS have a macro to do TCP/IP? I could hide the
stuff in the macro, but the executable would still
not be portable without an SVC.
BFN. Paul.

Sterling Garwood

2008-07-01 02:51:03 UTC

IIRC (its been a long time ... ) IBM's MVS/MVT TCPIP implemented a
sockets like interface.
I don't recall if the interface was assembler or (believe it not)
Pascal - the code in Wiscnet which begat FAL was in IBM Pascal.
Has anyone looked for Wiscnet source, talked to the U of Wisc about
the source, etc etc etc ???
Wiscnet was VM but could be easily ported to MVS I suspect (if you had
a Pascal compiler).

UCLA tcpip became one of the MVS TCPIP implementations. Does UCLA have
source code still? IIRC it was assembler.

What about some of the commercial products (KNet, et al)??? Any source
code that can be open sourced there?

It seems to me that re-re-re-inventing the wheel is not a practical
way to advance.

Post by kerravon86

Post by Jim Morrison
Check out the IP stack in CBT tape file 571 (archived in a huge
collection archive member somewhere). IIRC the base stack,
UDP protocol, and ICMP protocol were working at a proof of concept
level as archived. The base for the implementation was Dr. Comer's
Xinu design and implementation, ported to MVS38j (C and assembler).
The TCP protocol implementation was never ported, altho Dr. Comer
did provide one. See also the URL below for further details.

Post by time2ipl
(http://www.cbttape.org/~jmorrison/mvs38j-ip/index.html)

This link hasn't been updated for 5 years. Is that
correct that no work has been done for 5 years?
It pointed to a Yahoo group that doesn't seem to
exist, and an ftp site which also doesn't exist.
It mentioned that only C bindings were available.
Can someone tell me what C function(s) are required?
I'm trying to guess how the opcode 75 was implemented.
Depending on the parameters that were passed to the
C function, the C function could have bundled up those
parameters, pointed a register to them, then executed
the op code. The op code could then have demangled them
and called some native function by the same name.
Seems straightforward.
Although I think I would make the op code designed to
operate on a stack of registers for all the different
parameters required. And just save those registers
as normal before executing the instruction.
It would mean you couldn't port the executables
outside Hercules, but source code compatibility would
remain.
Does MVS have a macro to do TCP/IP? I could hide the
stuff in the macro, but the executable would still
not be portable without an SVC.
BFN. Paul.
------------------------------------
Yahoo! Groups Links

Jim Morrison

2008-07-01 08:03:10 UTC

Post by kerravon86

Post by time2ipl
(http://www.cbttape.org/~jmorrison/mvs38j-ip/index.html)

This link hasn't been updated for 5 years. Is that
correct that no work has been done for 5 years?
It pointed to a Yahoo group that doesn't seem to
exist, and an ftp site which also doesn't exist.

The CBT crew asked me to preserve that page as documentation
for the final IP stack offering in cbttape.org file 571, and
I was happy to oblige. The Yahoo group and ftp site are indeed
gone; all that remains available is in CBT file 571, on the off
chance that someone will pick it up again and run with it. At
the very least it offers some fun code to read, as long as you
ignore the simple-minded buffering scheme (way too much CSA).

At this point it is extremely unlikely that I'll revisit the IP
stack code in CBT file 571 to offer it as a free facility. If
I get excited about it again, maybe as a commercial offering but
that would entail quite a bit of change to remove Dr. Comer's
code; I wouldn't feel right selling a port of his code, even
with my extensive mods. Frankly I have deep misgivings about
how many people would actually pay for a commercial MVS38j IP
stack and a handful of applications ... which makes it a risky
proposition that I'd ever make as much as minimum wage for my
work. I can think of several more rewarding ways to spend my
time.

Post by kerravon86
It mentioned that only C bindings were available.

For those that want a Roll Your Own experience, the assembler
code is lying right there. I just never documented how to use
it. IIRC the C bindings used the assembler API code. Back in
those days I was concentrating on C bindings for ease of porting
readily available applications (FTP, etc.).

Were I to do things today, I'd likely look at using something
like IBM's IEZSOK (much as Jason did). Doing so might allow (for
instance) GCC[MVS] to use one interface to whatever IP stack one
chose across MVS38j to z/OS (ignoring 64-bitness). It might even
be a good idea to look at the current GCC code to see how they do
the z/OS IP stack (assuming they do) and use the same techniques
if possible.

Post by kerravon86
Can someone tell me what C function(s) are required?

Required for what? If you mean what C functions are required
to implement an IP stack in a C compiler, my answer is in the
next paragraph. If you mean something else, just say so.

Lo these many years ago, someone told me a bunch of their C
compiler internals with the caveat that I respect them as
Internal Use Only knowledge. The answer to your question, to
my way of thinking, falls within that domain so I cannot.
Someone else might, or you could think about it for awhile and
probably figure it out. It is, as the saying goes, intuitively
obvious.

Post by kerravon86
I'm trying to guess how the opcode 75 was implemented.

I don't really have much to say about Jason's implementation.
He and I had some initial discussions, but I never seriously
looked at his code to see how much of what we discussed made
it into the code. As I said above, I did like the IEZSOK idea.
As I recall, the bulk of his effort was in the Hercules code
including (IIRC) posting an OS ECB from there. Yikes, I hope
the Hercules developers fixed that! Anyway, you don't have to
guess about the Hercules part, the X'75' opcode source is included
in the Hercules source distro.

halfmeg

2008-07-01 17:58:06 UTC

Post by rfochtman
<snip>
Anyway, you don't have to guess about the Hercules part, the X'75'
opcode source is included in the Hercules source distro.

I thought so also until I looked for it the other day. I didn't find
it in the source tarball.

Phil - then again my eyes could be playing tricks on me

Jim Morrison

2008-07-01 21:31:19 UTC

Post by halfmeg

Post by rfochtman
Anyway, you don't have to guess about the Hercules part, the X'75'
opcode source is included in the Hercules source distro.

I thought so also until I looked for it the other day. I didn't find
it in the source tarball.
Phil - then again my eyes could be playing tricks on me

Nope, turns out your eyes are fine. My suspicion is that the
m38tcp.tar.bz2 here in the H390-MVS files area is the latest & greatest.

http://tech.groups.yahoo.com/group/H390-MVS/message/7045

HTH

Jim Morrison

2008-07-01 21:36:55 UTC

Post by Jim Morrison
like IBM's IEZSOK

Oops, make that EZASOKET. Sheez, 3am posts are such a dumb idea :-/

David Wade

2008-07-01 20:41:25 UTC

Post by kerravon86
Can someone tell me what C function(s) are required?

It appears that for a full socket interface you need:-

int accept(int socket, struct sockaddr *address,
socklen_t *address_len);
int bind(int socket, const struct sockaddr *address,
socklen_t address_len);
int connect(int socket, const struct sockaddr *address,
socklen_t address_len);
int getpeername(int socket, struct sockaddr *address,
socklen_t *address_len);
int getsockname(int socket, struct sockaddr *address,
socklen_t *address_len);
int getsockopt(int socket, int level, int option_name,
void *option_value, socklen_t *option_len);
int listen(int socket, int backlog);
ssize_t recv(int socket, void *buffer, size_t length, int flags);
ssize_t recvfrom(int socket, void *buffer, size_t length,
int flags, struct sockaddr *address, socklen_t
*address_len);
ssize_t recvmsg(int socket, struct msghdr *message, int flags);
ssize_t send(int socket, const void *message, size_t length, int
flags);
ssize_t sendmsg(int socket, const struct msghdr *message, int flags);
ssize_t sendto(int socket, const void *message, size_t length, int
flags,
const struct sockaddr *dest_addr, socklen_t dest_len);
int setsockopt(int socket, int level, int option_name,
const void *option_value, socklen_t option_len);
int shutdown(int socket, int how);
int socket(int domain, int type, int protocol);
int socketpair(int domain, int type, int protocol,
int socket_vector[2]);

More details on how they work here:-

http://www.cis.temple.edu/~ingargio/cis307/readings/unix4.html

Post by kerravon86
I'm trying to guess how the opcode 75 was implemented.
Depending on the parameters that were passed to the
C function, the C function could have bundled up those
parameters, pointed a register to them, then executed
the op code. The op code could then have demangled them
and called some native function by the same name.

Thats aboout what happened. There was a function code added that
mapped onto the 17 calls above...

Post by kerravon86
Seems straightforward.
Although I think I would make the op code designed to
operate on a stack of registers for all the different
parameters required. And just save those registers
as normal before executing the instruction.
It would mean you couldn't port the executables
outside Hercules, but source code compatibility would
remain.
Does MVS have a macro to do TCP/IP? I could hide the
stuff in the macro, but the executable would still
not be portable without an SVC.

No MVS doesn't have a MACRO to do TCP/IP. The original TCP/IP for
mainframe was done on VM/SP in PASCAL. It used a VM feature called
IUCV (Inter User Communications Vehicle) to pass the data between
VM's. MVS didn't have IUCV and it was added at some point to allow
TCP/IP to work on MVS. I have no idea if a modern zVM application can
still access TCP/IP this way. Any way IUCV uses another stolen OP
Code. There are some details are here:-

http://www.geocities.com/sim390/techinfo.htm

But if you put the IUCV support into Hercules rather than MVS you
could do a similar trick to the DYN75 and have some compatability at
the object code level...

Post by kerravon86
BFN. Paul.

Night Hight
Dave.

kerravon86

2008-07-02 12:41:53 UTC

Post by David Wade
int accept(int socket, struct sockaddr *address,
socklen_t *address_len);
int bind(int socket, const struct sockaddr *address,
socklen_t address_len);

Post by kerravon86
I'm trying to guess how the opcode 75 was implemented.
Depending on the parameters that were passed to the
C function, the C function could have bundled up those
parameters, pointed a register to them, then executed
the op code. The op code could then have demangled them
and called some native function by the same name.

Thats aboout what happened. There was a function code added that
mapped onto the 17 calls above...

Sounds doable. And if opcode 75 is already available,
then just the first bit is required, which means no
messing with Hercules. All that's required is to know
the interface to opcode 75 which should amount to
something like 10 lines of assembler code and maybe
200 lines of C code.

But it sounds like that is already done too, and all
that is required is a bug fix to GCCMVS which has
probably already been done, because there were indeed
bugs with file closes (which I fixed when I found, but
weren't ever reported to me).

I'll wait until I understand what's actually missing.
No point writing even 200 lines of code when the job
has already been done and just no-one has ever tried
it. Perhaps the original requestor would like to try
what's apparently already there? I can assist in
fixing any GCCMVS (more likely PDPCLIB bug) to do with
file closes on the way.

BFN. Paul.

halfmeg

2008-07-01 03:06:14 UTC

Post by rfochtman
<snip>
From what I've been able to gather, Jason's code has been available
under a variety of licensing schemes. According to this page, his
TCP/IP package was "please send cash-ware"
(http://www.cbttape.org/~jmorrison/mvs38j-ip/index.html); it had
been available at http://tech.groups.yahoo.com/group/H390-MVS/files/
(m38tcp.tar.bz2, Jason Winter's TCP/IP instruction) but has
apparently been taken down as the link to it is "dead"; with respect
to "the jcc compiler", this message intimates that he's using a
"user class" (i.e., student, hobbyist, professional, etc.) type
http://osdir.com/ml/emulators.turnkey-mvs/2004-11/msg00039.html.
So, I think "what license is ____ covered under?" is, at least in
part, a function of time...

I haven't looked at Jason's licensing statement in the m38tcp.tar.bz2
file for a long while. Don't think that is the problem any way. The
missing JCC compiler is the bigger obstacle. DCC might solve that
issue but have never messed with DCC.

When creating the TK3 Shadow Update we tinkered around with the TCP/IP
package for inclusion but were only able to get transfers out of MVS
3.8j to work properly. The transfer in worked until the dataset
needed closing and then the process hung for some unknown reason. The
possibility that compilation with GCCMVS instead of JCC may have
exposed a bug in GCCMVS is possible. There have been subsequent bug
squashing in GCCMVS since the attempt. I have recently decided to try
to pinpoint the problem and include TCP/IP for MVS 3.8j ( using the
dyn75 dynamic instruction module ) for inclusion in an update to TK3.

There were some more tinkering with the TCP/IP stuff by a couple of
folks. Their work is in the files section:

http://tech.groups.yahoo.com/group/H390-MVS/files/TCP-IP%20Dynamic%20Module/

Post by rfochtman
The third potential solution you've got listed - the bi-sync to IP
line driver - are you thinking about just using the line, or
full-blown BTAM? If it's possible to get a bisync line up and
running without too much of a hassle, that would seem to be the
cleanest way to do this...
<snip>

TK3 Shadow Update fixed the TK3 MVS image to allow a 2703 connection.

What kind of communication do you actually need between the mainframe
and other environments?

Phil - ruminations of a newbie :-)

time2ipl

2008-07-05 16:59:57 UTC

<snip>

Post by halfmeg
When creating the TK3 Shadow Update we tinkered around with the TCP/IP
package for inclusion but were only able to get transfers out of MVS
3.8j to work properly. The transfer in worked until the dataset
needed closing and then the process hung for some unknown reason. The
possibility that compilation with GCCMVS instead of JCC may have
exposed a bug in GCCMVS is possible. There have been subsequent bug
squashing in GCCMVS since the attempt. I have recently decided to try
to pinpoint the problem and include TCP/IP for MVS 3.8j ( using the
dyn75 dynamic instruction module ) for inclusion in an update to TK3.

The problem being a gcc <-> other is entirely possible, and is a snag
I've run up against on the *NIX side several times; as you're probably
aware, on more than one occasion, compiler version changes have
resulted in kernels that didn't work, wouldn't compile, or both...

Post by halfmeg
There were some more tinkering with the TCP/IP stuff by a couple of

http://tech.groups.yahoo.com/group/H390-MVS/files/TCP-IP%20Dynamic%20Module/
Ah. Thanks...

While I was there, I tried the link to m38tcp.tar.bz2; this time, it
worked. I've since managed to get it to compile, which was a bit
tricky, but AFAICT it worked; I included the dyn75.so that I built in
the .cnf file that I used when I last started Hercules. I didn't see
any errors, Hercules didn't crash, it's been running just fine; I
haven't had a chance to do anything more with it yet, though, so I
don't know if it works, etc.

The output from readelf looks ok; I'm not getting any messages from
Hercules at startup time that indicate that it loaded, though, so I'm
really not sure at this point as to whether it even built properly on
the *NIX end...

Post by halfmeg

Post by time2ipl
The third potential solution you've got listed - the bi-sync to IP
line driver - are you thinking about just using the line, or
full-blown BTAM? If it's possible to get a bisync line up and
running without too much of a hassle, that would seem to be the
cleanest way to do this...
<snip>

TK3 Shadow Update fixed the TK3 MVS image to allow a 2703 connection.
What kind of communication do you actually need between the mainframe
and other environments?

At a minimum, I need to be able to transfer a dataset to a computer
running MVS, initiate the processing of that data, and then, pick up
the results later.

It'd be nice if I could somehow pull off the real-time exchange of
data between a program running under MVS - or TSO on MVS... The
optimal solution would be one that let me run an email client
interactively, run a web server, or pretty much anything in between...

So I suppose the answer would be "whatever I can get". Optimally,
TCP/IP communication between MVS and the Hercules host O/S; if that's
not feasible, then serial - I should be able to route that through the
serial/PPP driver, like I've done with a number of other serial
gadgets (yeah, I did "surf the web" in text mode using my Palm m105.
It was there...)

What's killing me here more than anything, I think, is that my MVS
experience is VERY stale; the last time I worked with a mainframe was
c. 1992; the last time I worked with MVS && TSO directly was c. 1988.
And, unfortunately, it ain't like riding a bike...

Thanks,

Larry

kerravon86

2008-07-06 01:40:45 UTC

Post by time2ipl
While I was there, I tried the link to m38tcp.tar.bz2; this time, it
worked. I've since managed to get it to compile, which was a bit
tricky, but AFAICT it worked; I included the dyn75.so that I built in
the .cnf file that I used when I last started Hercules. I didn't see
any errors, Hercules didn't crash, it's been running just fine; I
haven't had a chance to do anything more with it yet, though, so I
don't know if it works, etc.

Can you document what you needed to do to overcome
the trickiness in case that is required in the future?

Post by time2ipl
At a minimum, I need to be able to transfer a dataset to a computer
running MVS, initiate the processing of that data, and then, pick up
the results later.

The solution I use for that is to run a program
called mvsendec on the PC, and have an mvsendec
on the mainframe, and basically generate a job
to dump all the data into a JCL file with instream
data.

And I have another program that takes the output
from the printer.

I use this combination to send and receive zip files.

You can see an example of this in any application I
have compiled for MVS, e.g. sed, available at:

http://gccmvs.sourceforge.net

The program to extract from the output (extzip) is
part of PDPCLIB from:

http://pdos.sourceforge.net

And precompiled MVS executables for zip etc are
provided as part of:

http://mvs380.sourceforge.net

which will also work on a non-380 platform (ie MVS 3.8j).

Probably minizip is the best example, as the test JCL
produces a zip file at the end (as a test).

BFN. Paul.

Grzes Plucinski

2008-07-06 08:48:32 UTC

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
</head>

<body style="background-color: #ffffff;">


<div id="ygrp-mlmsg" style="width:655px; position:relative;">
<div id="ygrp-msg" style="width: 470px; margin:0; padding:0 25px 0 0; float:left; z-index:1;">


<div id="ygrp-text">
<p><!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<tt>Hi,<br>
<br>
I use my own program as exit to HERCULES <br>
(documented)<br>
<br>
from the MVS side this is DIAGNOSE instruction (code F14)<br>
from the linux side this is ipc socket<br>
<br>
it's work fine<br>
<br>
Gregor<br>
<br>
<br>
</tt><br>
kerravon86 pisze:
<blockquote cite="mid:g4p7qt+cel5-***@public.gmane.org" type="cite">
<div id="ygrp-text">
<p>--- In <a moz="true" href="mailto:H390-MVS%40yahoogroups.com">H390-***@yahoogroup<wbr>s.com</a>,
"time2ipl" <***@...<wbr>> wrote:<br>
><br>
> While I was there, I tried the link to m38tcp.tar.bz2; this time,
it<br>
> worked. I've since managed to get it to compile, which was a bit<br>
> tricky, but AFAICT it worked; I included the dyn75.so that I built
<br>
in<br>
> the .cnf file that I used when I last started Hercules. I didn't <br>
see<br>
> any errors, Hercules didn't crash, it's been running just fine; I<br>
> haven't had a chance to do anything more with it yet, though, so I<br>
> don't know if it works, etc.<br>
<br>
Can you document what you needed to do to overcome<br>
the trickiness in case that is required in the future?<br>
<br>
> At a minimum, I need to be able to transfer a dataset to a computer<br>
> running MVS, initiate the processing of that data, and then, pick
up<br>
> the results later.<br>
<br>
The solution I use for that is to run a program<br>
called mvsendec on the PC, and have an mvsendec<br>
on the mainframe, and basically generate a job<br>
to dump all the data into a JCL file with instream<br>
data.<br>
<br>
And I have another program that takes the output<br>
from the printer.<br>
<br>
I use this combination to send and receive zip files.<br>
<br>
You can see an example of this in any application I<br>
have compiled for MVS, e.g. sed, available at:<br>
<br>
<a moz="true" href="http://gccmvs.sourceforge.net">http://gccmvs.<wbr>sourceforge.<wbr>net</a><br>
<br>
The program to extract from the output (extzip) is <br>
part of PDPCLIB from:<br>
<br>
<a moz="true" href="http://pdos.sourceforge.net">http://pdos.<wbr>sourceforge.<wbr>net</a><br>
<br>
And precompiled MVS executables for zip etc are<br>
provided as part of:<br>
<br>
<a moz="true" href="http://mvs380.sourceforge.net">http://mvs380.<wbr>sourceforge.<wbr>net</a><br>
<br>
which will also work on a non-380 platform (ie MVS 3.8j).<br>
<br>
Probably minizip is the best example, as the test JCL<br>
produces a zip file at the end (as a test).<br>
<br>
BFN. Paul.<br>
<br>
</p>
</div>
 </blockquote>

</p>
</div>


<span width="1" style="color: white;">__._,_.___</span>

<div id="ygrp-actbar">
<span class="left">
<a href="http://groups.yahoo.com/group/H390-MVS/message/8780;_ylc=X3oDMTM0cGVhYWFkBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BG1zZ0lkAzg4MDkEc2VjA2Z0cgRzbGsDdnRwYwRzdGltZQMxMjE1MzM0MTI0BHRwY0lkAzg3ODA-">
Messages in this topic </a> (<span class="bld">26</span>)
</span>
<a href="http://groups.yahoo.com/group/H390-MVS/post;_ylc=X3oDMTJwOWNiNXNtBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BG1zZ0lkAzg4MDkEc2VjA2Z0cgRzbGsDcnBseQRzdGltZQMxMjE1MzM0MTI0?act=reply&messageNum=8809">
<span class="bld">
Reply </span> (via web post)
</a> |
<a href="http://groups.yahoo.com/group/H390-MVS/post;_ylc=X3oDMTJlaGEzYW1xBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTIxNTMzNDEyNA--" class="bld">
Start a new topic </a>
</div>


<div id="ygrp-vitnav">
<a href="http://groups.yahoo.com/group/H390-MVS/messages;_ylc=X3oDMTJlMmVqbGFzBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNmdHIEc2xrA21zZ3MEc3RpbWUDMTIxNTMzNDEyNA--">Messages</a>
| <a href="http://groups.yahoo.com/group/H390-MVS/files;_ylc=X3oDMTJmdXJjMzBxBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNmdHIEc2xrA2ZpbGVzBHN0aW1lAzEyMTUzMzQxMjQ-">Files</a>
| <a href="http://groups.yahoo.com/group/H390-MVS/photos;_ylc=X3oDMTJlY2diZThqBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNmdHIEc2xrA3Bob3QEc3RpbWUDMTIxNTMzNDEyNA--">Photos</a>
| <a href="http://groups.yahoo.com/group/H390-MVS/links;_ylc=X3oDMTJmbnE1NDJqBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNmdHIEc2xrA2xpbmtzBHN0aW1lAzEyMTUzMzQxMjQ-">Links</a>

| <a href="http://groups.yahoo.com/group/H390-MVS/members;_ylc=X3oDMTJlOThvOG9lBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNmdHIEc2xrA21icnMEc3RpbWUDMTIxNTMzNDEyNA--">Members</a>

</div>


<div id="ygrp-mkp">
<div id="hd">MARKETPLACE</div>
<div id="ads">
<div class="ad">
<hr size=1 noshade><a href="http://us.ard.yahoo.com/SIG=13rbhaf4k/M=624381.12730922.13032918.10835568/D=groups/S=1705309548:MKP1/Y=YAHOO/EXP=1215341324/L=/B=xxxlCULaX9w-/J=1215334124736084/A=5396693/R=0/SIG=14ete9fpo/*http://media.adrevolver.com/adrevolver/href?banner=197793&place=26143&url_=http://tc.deals.yahoo.com/tc/blockbuster/display.com?cid=bbi00027
"> Yahoo! Groups users, </a> take advantage of a<a href="http://us.ard.yahoo.com/SIG=13rbhaf4k/M=624381.12730922.13032918.10835568/D=groups/S=1705309548:MKP1/Y=YAHOO/EXP=1215341324/L=/B=xxxlCULaX9w-/J=1215334124736084/A=5396693/R=1/SIG=14ete9fpo/*http://media.adrevolver.com/adrevolver/href?banner=197793&place=26143&url_=http://tc.deals.yahoo.com/tc/blockbuster/display.com?cid=bbi00027
"> free trial offer from Blockbuster!</a> </div>
</div>
</div>



<div id="ygrp-ft">
<a href="http://groups.yahoo.com/;_ylc=X3oDMTJkZHJoc3M4BF9TAzk3NDc2NTkwBGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxMjE1MzM0MTI0">
<img src="Loading Image...

" height="15" width="106" border="0" alt="Yahoo! Groups"></a> <br>
<a href="http://groups.yahoo.com/group/H390-MVS/join;_ylc=X3oDMTJmdWY1NDF0BF9TAzk3NDc2NTkwBGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyMTUzMzQxMjQ-">Change settings via the Web</a> (Yahoo! ID required) <br>
Change settings via email: <a href="mailto:H390-MVS-digest-***@public.gmane.org?subject=Email Delivery: Digest">Switch delivery to Daily Digest</a> | <a href = "mailto:H390-MVS-traditional-***@public.gmane.org?subject=Change Delivery Format: Traditional">Switch format to Traditional</a> <br>

<a href="http://groups.yahoo.com/group/H390-MVS;_ylc=X3oDMTJkM2ptbjdtBF9TAzk3NDc2NTkwBGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjE1MzM0MTI0">
Visit Your Group
</a> |
<a href="http://docs.yahoo.com/info/terms/">
Yahoo! Groups Terms of Use </a> |
<a href="mailto:H390-MVS-unsubscribe-***@public.gmane.org?subject=">
Unsubscribe </a>
</div> 
</div> 



<div id="ygrp-sponsor" style="width:160px; float:right; clear:none; margin:0 0 25px 0; background:white;">



<div id="ygrp-reco">
</div>



<div id="ygrp-vital">
<div id="vithd">Recent Activity</div>
<ul style="list-style-type:none; padding: 0; margin: 2px 0;">
<li style="clear: both;">
<div class="ct" style="float: right;"><span style="display:none"> </span>3</div>
<div class="cat"><a href="http://groups.yahoo.com/group/H390-MVS/members;_ylc=X3oDMTJmdGg3NzF2BF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzEyMTUzMzQxMjQ-">New Members</a></div>
</li>

</ul>
<a href="http://groups.yahoo.com/group/H390-MVS;_ylc=X3oDMTJldm83ZmJqBF9TAzk3MzU5NzE0BGdycElkAzI1ODc5NjYEZ3Jwc3BJZAMxNzA1MzA5NTQ4BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTIxNTMzNDEyNA--">
Visit Your Group </a>
</div>


<div id="nc">
<div class="ad">
<div id="hd1">Search Ads</div>
<p><a href="http://us.ard.yahoo.com/SIG=13o3bk2el/M=493064.12016308.12445700.8674578/D=groups/S=1705309548:NC/Y=YAHOO/EXP=1215341324/L=/B=yBxlCULaX9w-/J=1215334124736084/A=3848641/R=0/SIG=1312g85fq/*http://searchmarketing.yahoo.com/arp/srchv2.php?o=US2003&cmp=Yahoo&ctv=Groups2&s=Y&s2=&s3=&b=50">Get new customers.</a></p>
<p>List your web site</p>
<p>in Yahoo! Search.</p> </div>
<div class="ad">
<div id="hd1">Find helpful tips</div>
<p><a href="http://us.ard.yahoo.com/SIG=13or47f5f/M=493064.12016258.12582637.8674578/D=groups/S=1705309548:NC/Y=YAHOO/EXP=1215341324/L=/B=yRxlCULaX9w-/J=1215334124736084/A=5191954/R=0/SIG=112mhte3e/*http://www.ygroupsblog.com/blog/">for Moderators</a></p>
<p>on the Yahoo!</p>
<p>Groups team blog.</p> </div>
<div class="ad">
<div id="hd1">Yahoo! Groups</div>
<p><a href="http://us.ard.yahoo.com/SIG=13o4d9in2/M=493064.12016263.12445670.8674578/D=groups/S=1705309548:NC/Y=YAHOO/EXP=1215341324/L=/B=yhxlCULaX9w-/J=1215334124736084/A=4836041/R=0/SIG=11o19ppl5/*http://advision.webevents.yahoo.com/dogzone/index.html">Dog Zone</a></p>
<p>Connect w/others</p>
<p>who love dogs.</p> </div>
</div>

</div> 
<div style="clear:both; color: #FFF; font-size:1px;">.</div>
</div> <img src="http://geo.yahoo.com/serv?s=97359714/grpId=2587966/grpspId=1705309548/msgId=8809/stime=1215334124/nc1=3848641/nc2=5191954/nc3=4836041" width="1" height="1"> <br>

<span style="color: white;">__,_._,___</span>

</body>

<head>
<style type="text/css">

</style>
</head>
<head>
<style type="text/css">

</style>
</head>
<head>
<style type="text/css">

</style>
</head>

</html>

time2ipl

2008-07-09 04:49:28 UTC

Hi, Paul

Post by kerravon86
Can you document what you needed to do to overcome
the trickiness in case that is required in the future?

Definitely. It probably got lost several messages ago, but I stated
then that I would (a) make whatever I managed to cook up freely
available to anyone who wanted it and (b) would thoroughly document it
(whatever it turned out to be on both fronts).

It sounds like you're already doing pretty much what I'm trying to get

Post by kerravon86

Post by time2ipl
At a minimum, I need to be able to transfer a dataset to a computer
running MVS, initiate the processing of that data, and then, pick up
the results later.

The solution I use for that is to run a program
called mvsendec on the PC, and have an mvsendec
on the mainframe, and basically generate a job
to dump all the data into a JCL file with instream
data.

I've been experimenting with the vmnet code - I have 1.3 and 1.4 - and
an assembler program in a file named CTCAMAIN.VS1. At this point, it
certainly feels like I'm very close to having something workable v/v
exchange of data over a CTC adapter <-> the Hercules host OS's TCP/IP
stack (under *NIX, anyway; I already know all too well that TCP/IP
under Windows is - I'll be kind here - different).

The main problem at this point is me, and the fact that I haven't
touched an MVS system since ca. 1988. It's coming back to me; in the
last few weeks, I've managed to successfully sysgen a system, install
RPF 1.53 from source, etc. I still don't get the feeling yet that I
know what the hell I'm doing, though. You wouldn't happen to know
what, exactly, the CTCAMAIN.VS1 code that I found (it was in the
group's Files section) does, would you?

At this point, what I'm thinking, is this: Hercules can emulate a CTC
adapter; that should provide me - assuming I have routing and
forwarding configured correctly on the host Hercules is running on -
with an on-ramp onto "the network".

Alternatively - and this is almost too painful to even think about - I
could use the BISYNC adapter to do something similar; the very thought
of it is making me cringe.

What I like about the solution I'm thinking about is that it's "more
general purpose"; it literally would give any app that ran under MVS
that was able to utilize the CTC adapter, network connectivity. It
would be possible to extend that basic design and turn it into a
TCP/IP protocol stack, essentially masquerading as a CTC adapter (or a
synchronous serial line).

The only problem I see with both / either is I'm going to end up
writing "ping", "ftp", et. al. under MVS. Which is fine; as long as
the underlying principle is sound, I can live with that.

Does that sound about right? Also, if anyone can give me any guidance
w respect to "CTCAMAIN.VS1" (what it does, how to build it and set it
up, etc.) I'd really appreciate it.

Thanks again,
Larry

Post by kerravon86
And I have another program that takes the output
from the printer.
I use this combination to send and receive zip files.
You can see an example of this in any application I
http://gccmvs.sourceforge.net
The program to extract from the output (extzip) is
http://pdos.sourceforge.net
And precompiled MVS executables for zip etc are
http://mvs380.sourceforge.net
which will also work on a non-380 platform (ie MVS 3.8j).
Probably minizip is the best example, as the test JCL
produces a zip file at the end (as a test).
BFN. Paul.

kerravon86

2008-07-09 10:14:13 UTC

Post by time2ipl
I've been experimenting with the vmnet code - I have 1.3 and 1.4 - and
an assembler program in a file named CTCAMAIN.VS1. At this point, it
certainly feels like I'm very close to having something workable v/v
exchange of data over a CTC adapter <-> the Hercules host OS's

Way above my head I'm afraid. zip I know how to get
working.

BTW, back in the mainframe days was there ever the
ability to access a normal modem so that you could
dial a bulletin board and download data?

Something I wanted to do. :-)

Also, what would be required for a graphics terminal
on MVS 3.8j running a web browser?

I'm not planning on implementing that. Just wondering
whether the appropriate hardware and system calls were
ever available.

BFN. Paul.

rfochtman

2008-07-09 15:10:22 UTC

--------------------<snip>---------------
BTW, back in the mainframe days was there ever the
ability to access a normal modem so that you could
dial a bulletin board and download data?

Something I wanted to do. :-)
----------------------<unsnip>--------------------
Afraid not. You had to use the modem to do the dialing. The old
xx61-series of modems had a dial-out capability via the front panel.

----------------------<snip>----------------
Also, what would be required for a graphics terminal on MVS 3.8j
running a web browser?
--------------------<unsnip>------------------
IIRC, the only "graphics" device supported by MVS was a 2250 or 3250
Vector Graphics Workstation; that support was via the Graphics Access
Method ("GAM")

Greg Price

2008-07-10 12:03:14 UTC

Post by rfochtman
IIRC, the only "graphics" device supported by MVS was a 2250 or 3250
Vector Graphics Workstation; that support was via the Graphics Access
Method ("GAM")

We used to drive Tektronix terminals via TCAM running IGGS under TSO
circa 1980. I think IBM replaced IGGS with GPG or whatever it was called.

Cheers,
Greg

time2ipl

2008-07-09 15:51:54 UTC

Post by kerravon86

Post by time2ipl
I've been experimenting with the vmnet code - I have 1.3 and 1.4 - and
an assembler program in a file named CTCAMAIN.VS1. At this point, it
certainly feels like I'm very close to having something workable v/v
exchange of data over a CTC adapter <-> the Hercules host OS's

Way above my head I'm afraid. zip I know how to get
working.
BTW, back in the mainframe days was there ever the
ability to access a normal modem so that you could
dial a bulletin board and download data?
Something I wanted to do. :-)

He he - sounds like we're like-minded in several regards...

As far as the modem goes, I worked with several systems where the
mainframe was driving a synchronous serial modem @ 9600 baud using the
X.25 protocol; in this area (northeastern NY, about 3 1/2 hours NW of
NYC) lines like that were common as late as the mid 1990's, possibly
even later (I moved - again - right around then) and had sufficient
capacity to string 20-some 3279 terminals and a high-speed line
printer off of.

That's a vastly different creature than an async serial line, though;
I can't recall any time I ever used an async serial line / dial-up
line to converse with a mainframe. I think the main reason why not
wasn't so much a technical decision as it was business one; most
everywhere I've worked with a mainframe, the thing was in around the
clock use, the goal being to get CPU utilization up around the 80 to
90 percent mark and keep it there, 24x7.

If you needed to use a BBS, or the early Internet, you were pointed
towards one of the *NIX systems, or a PC; actually, I remember the
modem being a shared device managed by the "LANMan" (IBM/Microsoft LAN
Manager) server to which it was physically attached.

Post by kerravon86
Also, what would be required for a graphics terminal
on MVS 3.8j running a web browser?

I'm not sure what you're asking - are you asking if it'd be possible
to run a web browser on a graphics terminal connected to a mainframe?
If "yes", if you have two *NIX systems, try running a sizeable
graphical X app on one and having it render on the X server running on
the other; on a 10Mbps Ethernet, it works, but it is s - l - o - w ...

It used to be pretty commonplace to develop X11 apps (ranging from
"raw X" to Motif widget toolkit apps) on DEC VAXs, were sorta kinda
intended for that purpose; before that, there was the venerable VT52
and REGIS graphics. About the extent of the graphical output I ever
saw coming out of a mainframe was charts, etc. - essentially,
graphical views of reports. Even in that fairly limited realm, the
killer was always bandwidth (the lack of bandwidth).

Post by kerravon86
I'm not planning on implementing that. Just wondering
whether the appropriate hardware and system calls were
ever available.

Any time I ever tried to get a mainframe to handle real-time user
input, I ate up a ton of bandwidth, and loaded up the processor. Even
simple things like "cls" programs, tended to be frowned on, on
mainframe systems.

Think about the user interaction model the mainframe uses - the
majority of input, editing, etc., was done on a 3270 type terminal;
the only time the processor had to deal with the user was (a) to set
up the display initially, and (b) when the user pressed <ENTER>. My
guess would be that it'd be possible (if one knew what they were
doing) to hook up an asynch modem, but I don't think you would stand
much of a chance of ever getting a web browser to run at an acceptable
degree of performance on a gfx term.

Interesting idea, though...

- Larry

scott

2008-07-09 17:21:21 UTC

Post by time2ipl

Post by kerravon86

Post by time2ipl
I've been experimenting with the vmnet code - I have 1.3 and 1.4 - and
an assembler program in a file named CTCAMAIN.VS1. At this point, it
certainly feels like I'm very close to having something workable v/v
exchange of data over a CTC adapter <-> the Hercules host OS's

Way above my head I'm afraid. zip I know how to get
working.
BTW, back in the mainframe days was there ever the
ability to access a normal modem so that you could
dial a bulletin board and download data?
Something I wanted to do. :-)

He he - sounds like we're like-minded in several regards...
As far as the modem goes, I worked with several systems where the
X.25 protocol; in this area (northeastern NY, about 3 1/2 hours NW of
NYC) lines like that were common as late as the mid 1990's, possibly
even later (I moved - again - right around then) and had sufficient
capacity to string 20-some 3279 terminals and a high-speed line
printer off of.
That's a vastly different creature than an async serial line, though;
I can't recall any time I ever used an async serial line / dial-up
line to converse with a mainframe. I think the main reason why not
wasn't so much a technical decision as it was business one; most
everywhere I've worked with a mainframe, the thing was in around the
clock use, the goal being to get CPU utilization up around the 80 to
90 percent mark and keep it there, 24x7.

I used a async dial-up line to both converse with both VM/CMS and
MVS/TSO. This was for non-full screen stuff. Worked well even though
it was 300 baud. The FEP was a regular 3705 running PEP/NCP/EP.

There was also a 3174 controller that IBM made, as well as another
vendor who made something called a Hydra, which allowed dumb ASCII
terminals to act like a 3270 terminal. This was using a 9600 baud
terminal and didn't work too bad.

time2ipl

2008-07-09 19:24:30 UTC

Hi, Paul -

I somehow chopped off part of my reply earlier; sorry.

Thanks for the links to PDOS && MVS/380; good stuff. I've got MVS/380
set up on the one windows machine I still have (there wasn't any
source code at sourceforge for Hercules/380; I probably just need to
RTFM more thoroughly). I've set aside the rest of this afternoon to
check out the both of them...

PDOS is particularly impressive. Talk about cross-platform
portability... Wow...

BTW: I'm still trying to track down the author of CTCAMAIN.VS1 (the
name of the program that's generated by the job in the file is
CTCAMAIN, if that helps ring any bells). I'm plodding my way through
the 370 assembler it's written in. Not quite like riding a bicycle, that.

Thanks again,

Larry

kerravon86

2008-07-09 22:39:20 UTC

Post by time2ipl
Thanks for the links to PDOS && MVS/380; good stuff. I've got

MVS/380

Post by time2ipl
set up on the one windows machine I still have (there wasn't any
source code at sourceforge for Hercules/380; I probably just need to
RTFM more thoroughly). I've set aside the rest of this afternoon to
check out the both of them...

I checked the release notes in sourceforge, and they
are deficient. I then tried to update them and had a
technical problem (release notes disappeared on me!).

Short story is - read the readme.s380 file, and then
take a look at hercules380-3_05-2_0.txt which is the
patch file you need. Don't be surprised at how small
it is. Supporting 31-bit mode wasn't difficult.

Post by time2ipl
PDOS is particularly impressive. Talk about cross-platform
portability... Wow...

PDOS or PDPCLIB? PDOS isn't cross-platform, it is
heavily dependent on the PC BIOS being available.

PDPCLIB is certainly cross-platform, as C is in
general. You don't need one C library to be cross
platform though. C libraries are meant to be
tailored to the environment. It's the users of the
C library who need to write their code portably so
that the result is cross-platform.

I have various examples of that too, but they're
not particular good - either small, obsolete, or
not standalone (e.g. PDPZM - public domain zmodem
implementation).

Certainly these things are a significant portion
of my life's (non-paid) work - probably 50%. The
other 50% you literally wouldn't believe.

BFN. Paul.

time2ipl

2008-07-10 02:20:54 UTC

<snip>

... I've set aside the rest of this afternoon to
check out the both of them...

I checked the release notes in sourceforge, and they ...

<snip>

... read the readme.s380 file, and then
take a look at hercules380-3_05-2_0.txt which is the
patch file you need. Don't be surprised at how small
it is. Supporting 31-bit mode wasn't difficult.

After I read that README, I started with a clean copy of the Herc 3.05
source, and in the directory I unpacked the tarball, I did:

patch -p1 --dry-run -i hercules380-3_05-2_0.txt

The patch applied cleanly... That's the 'right way' to get everything
ready to roll, right? I'm hoping it is, as I'd much rather do this on
Linux et al. as I generally only keep windows installed on one or two
physical machines.

PDOS is particularly impressive. Talk about cross-platform
portability... Wow...

PDOS or PDPCLIB? PDOS isn't cross-platform,...

Sorry. Yeah, I meant PDPCLIB. I guess the mind really is the first
thing to go...

I have various examples of that too, but they're
not particular good - either small, obsolete, or
not standalone (e.g. PDPZM - public domain zmodem
implementation).

Actually, I'd like to see that if you don't mind; I lost a number of
things a few years back when lightning hit our building. I've had a
need to use various parts of that app, like the CRC generation and
checking algorithm, from time to time.

Certainly these things are a significant portion
of my life's (non-paid) work - probably 50%. The
other 50% you literally wouldn't believe.

I hear you there. Now that I'm semi-retired, the bulk of what I do is
"non-paid". And, on average, a week now consists of close to twice as
many hours as it used to; no joke.

Things have remained proportionate, though, as I'm enjoying what I do
- and life in general - at least twice as much.

Take care, and again, thanks...

- Larry

kerravon86

2008-07-10 15:23:22 UTC

Post by time2ipl

... read the readme.s380 file, and then
take a look at hercules380-3_05-2_0.txt which is the
patch file you need. Don't be surprised at how small
it is. Supporting 31-bit mode wasn't difficult.

After I read that README, I started with a clean copy of the Herc 3.05
patch -p1 --dry-run -i hercules380-3_05-2_0.txt
The patch applied cleanly... That's the 'right way' to get

everything

Post by time2ipl
ready to roll, right?

Yes it is, although I've never done a patch that way
before. I do patch -p 1 <he....txt

Post by time2ipl
I'm hoping it is, as I'd much rather do this on
Linux et al. as I generally only keep windows installed on one or two
physical machines.

Sure. I haven't actually had any feedback from a Linux
user though, so it'll be good to know if it works.

Post by time2ipl

I have various examples of that too, but they're
not particular good - either small, obsolete, or
not standalone (e.g. PDPZM - public domain zmodem
implementation).

Actually, I'd like to see that if you don't mind; I lost a number of
things a few years back when lightning hit our building. I've had a
need to use various parts of that app, like the CRC generation and
checking algorithm, from time to time.

Maybe one day I'll move them off here:

http://home.exetel.com.au/kerravon/program.htm

(which I no longer even have access to anymore)

and onto the PDOS sourceforge page.

The CRC don't need to be extracted from the Zmodem.
They come as standalone routines, although the
specs and test data I got for one of the flavours
of CRC (one that's not used much) may be wrong.
Didn't ever resolve whether the published specs I
read were wrong.

CRC-32 etc are fine though - tested as part of Zmodem.

Post by time2ipl

Certainly these things are a significant portion
of my life's (non-paid) work - probably 50%. The
other 50% you literally wouldn't believe.

I hear you there. Now that I'm semi-retired, the bulk of what I do is
"non-paid". And, on average, a week now consists of close to twice as
many hours as it used to; no joke.

Yes, I can believe that.

Post by time2ipl
Things have remained proportionate, though, as I'm enjoying what I do
- and life in general - at least twice as much.
Take care, and again, thanks...

No problem. Let me know of any changes you would suggest
to the readme or anything else, especially Linux, as I
haven't really had any feedback on installation problems
so don't know what the issues are.

Quite disturbing that the release notes on sourceforge
have been gone for 18 hours or whatever now.

I finally managed to get some feedback on brexx though,
and the executable I produced did indeed work on another
person's system.

BFN. Paul.

time2ipl

2008-07-11 16:16:58 UTC

Paul,

I built a Linux version - a 32-bit, x86 one, but a Linux version
nonetheless - and it starts up fine; it even loads my "dyn75" (BTW,
I'm still not sure which code is "supposed" to be in that, the code in
m38tcp.tar.bz2, the code that's under "TCP-IP Dynamic Module" in the
Files section of this group, or both ...)

I'll get a chance to actually fire up MVS on it later this afternoon,
and I'll let you know what the results of that experiment are; thought
you might want to know that it did, in fact, build and run, for
starters, though.

... I do patch -p 1 <he....txt

Six of one, half-dozen of another as far as that goes; I had used "<",
too, but have lately gotten more into the habit of using "-i" (which
has the same thing net effect as "<") since some of the code I've been
working with uses that syntax exclusively.

W/ respect to the "--dry-run" switch: you can use that with either.
And it's great; you can see if you've got the right N for "-pN"
without actually messing anything up.

Take it easy

Larry

kerravon86

2008-07-11 19:36:02 UTC

Post by time2ipl
Paul,
I built a Linux version - a 32-bit, x86 one, but a Linux version
nonetheless - and it starts up fine; it even loads my "dyn75"

That's great. And you're incorporating the TCP/IP stuff
too which some people are after.

I'm in the process of making more mods to Hercules/380
to allow AMODE switching in BCMODE.

So maybe both of these changes should be incorporated
soon and a new version released.

Would you like to get involved in releasing the
Hercules/380 executables?

Post by time2ipl
(BTW,
I'm still not sure which code is "supposed" to be in that, the code in
m38tcp.tar.bz2, the code that's under "TCP-IP Dynamic Module" in the
Files section of this group, or both ...)

I don't know that.

Post by time2ipl
I'll get a chance to actually fire up MVS on it later this

afternoon,

Post by time2ipl
and I'll let you know what the results of that experiment are;

thought

Post by time2ipl
you might want to know that it did, in fact, build and run, for
starters, though.

Yep. I actually made Linux makefile changes from
memory, but never tested them.

Post by time2ipl

... I do patch -p 1 <he....txt

Six of one, half-dozen of another as far as that goes; I had

used "<",

Post by time2ipl
too, but have lately gotten more into the habit of using "-i" (which
has the same thing net effect as "<") since some of the code I've been
working with uses that syntax exclusively.

Yeah, just didn't want to commit myself to verifying
a command I'd never even used. :-)

Post by time2ipl
W/ respect to the "--dry-run" switch: you can use that with either.
And it's great; you can see if you've got the right N for "-pN"
without actually messing anything up.

Ok. When I was working with Peter one of the issues that
came up was being in the wrong directory when doing the
patch.

BFN. Paul.

time2ipl

2008-07-11 23:03:35 UTC

Hi, Paul

Post by kerravon86
That's great. And you're incorporating the TCP/IP stuff
too which some people are after.

Not the least of whom being me. I'm really hoping that works in a
halfway clean manner. Ultimately, I'm going to have to use the CTC
adapter, but the other will work for a proof of concept type model (I
think).

Post by kerravon86
I'm in the process of making more mods to Hercules/380
to allow AMODE switching in BCMODE.

Uh - I'm not sure what that means... I think BCMODE has something to
do with memory management, right? I've no idea WRT "AMODE"; nothing
turned up when I searched for it either.

Post by kerravon86
So maybe both of these changes should be incorporated
soon and a new version released.
Would you like to get involved in releasing the
Hercules/380 executables?

Sure. Just remember, my knowledge of mainframe systems is limited.

I'm having problems getting MVS/380 installed; here's where I'm at
with it (I hope this makes sense; I tried to be as descriptive as I
could ...)

I started out by making an mvs380 directory right off of "/":

mkdir /mvs380
export MVS380=/mvs380

Then I ran setup off of the toolkit CD:

./setup

When it completed, I changed my working directory to be /usr/src/HERCULES.

cd /usr/src/HERCULES

I had already "got" TK3SU1.zip, fixpack1.zip - just for reference, I
got them from www.softlib.org:
wget 'http://www.softlib.org/TK4Beta/TK3SU1.zip'
wget 'http://www.softlib.org/TK4Beta/fixpack1.zip'

With CWD == /usr/src/HERCULES, I unpacked TK3SU1.zip and mvs380.zip:
unzip TK3SU1.zip -d TK3SU1/
unzip mvs380-0_4.zip -d mvs380/

I set the cwd to the mvs380 sudir of /usr/src/HERCULES
(/usr/src/HERCULES/mvs380), where I had put the STARTMVS and RUNMVS
scripts I had "translated".

At this point, startmvs is expecting to find commit_shadow.rc and
mvs380.conf in ${MVS380}/conf. Which they're not; at this point, it's
the files from TK3 that are in ${MVS380}.

I tried copying over the mvs380 files onto ${MVS380} w
cp -av
/usr/src/HERCULES/mvs380/{build,conf,install,jcl,scripts,source} ${MVS380}

That "hung" during ./STARTMVS coldjes though (after 1/2 hour it still
hadn't completed; from what I could tell from ps, lsof, et al.,
hercules was hung up waiting for something.

I'm guessing I screwed up something that's fairly obvious, but I'll be
darned if I can find it (at the moment, anyway). I thought that this
might be a good time to ask someone who knows what they're doing...

Take it easy,

Larry

kerravon86

2008-07-11 23:25:02 UTC

Post by time2ipl

Post by kerravon86
I'm in the process of making more mods to Hercules/380
to allow AMODE switching in BCMODE.

Uh - I'm not sure what that means... I think BCMODE has something to
do with memory management, right? I've no idea WRT "AMODE"; nothing
turned up when I searched for it either.

Don't worry about BCMODE if you don't know what AMODE is.

I assumed you were downloading MVS/380 because you liked
the idea of 31-bit addressing. You want it for the C
compiler or tools, do you?

In brief, MVS/380 has the ability to use 2 GB of memory
instead of the normal 16 MB. But depending on what
you're doing, that may not be useful to you.

Post by time2ipl

Post by kerravon86
So maybe both of these changes should be incorporated
soon and a new version released.
Would you like to get involved in releasing the
Hercules/380 executables?

Sure. Just remember, my knowledge of mainframe systems is limited.

That's fine. It's actually compiling the stupid DLL
under Windows that I never figured out how to do
properly. I got stuck on the instruction "then fix
the broken Makefile". And I don't have Linux installed
either. Not sure if normal Hercules is distributed
as a Linux executable, but if it is, then so should
Hercules/380 ideally.

Post by time2ipl
I'm having problems getting MVS/380 installed; here's where I'm at
with it (I hope this makes sense; I tried to be as descriptive as I
could ...)
mkdir /mvs380
export MVS380=/mvs380
./setup

And you directed this to install into /mvs380, right?

Post by time2ipl
When it completed, I changed my working directory to

be /usr/src/HERCULES.

Post by time2ipl
cd /usr/src/HERCULES
I had already "got" TK3SU1.zip, fixpack1.zip - just for reference, I
wget 'http://www.softlib.org/TK4Beta/TK3SU1.zip'
wget 'http://www.softlib.org/TK4Beta/fixpack1.zip'
unzip TK3SU1.zip -d TK3SU1/
unzip mvs380-0_4.zip -d mvs380/

These things are meant to overwrite each other in the
same directory, not be installed into separate
directories.

Also, the overwriting is meant to happen in /mvs380,
not /hercules.

Post by time2ipl
I set the cwd to the mvs380 sudir of /usr/src/HERCULES
(/usr/src/HERCULES/mvs380), where I had put the STARTMVS and RUNMVS
scripts I had "translated".

mvs380 is not meant to be under HERCULES. It's the
other way around normally.

Post by time2ipl
At this point, startmvs is expecting to find commit_shadow.rc and
mvs380.conf in ${MVS380}/conf. Which they're not; at this point, it's
the files from TK3 that are in ${MVS380}.
I tried copying over the mvs380 files onto ${MVS380} w
cp -av
/usr/src/HERCULES/mvs380/{build,conf,install,jcl,scripts,source} ${MVS380}
That "hung" during ./STARTMVS coldjes though (after 1/2 hour it still
hadn't completed; from what I could tell from ps, lsof, et al.,
hercules was hung up waiting for something.
I'm guessing I screwed up something that's fairly obvious, but I'll be
darned if I can find it (at the moment, anyway). I thought that this
might be a good time to ask someone who knows what they're doing...

everything should end up in /mvs380

Install TK3 there first.
Overwrite that with TK3SU1 (that's why there's a -o in unzip)
Overwrite that with MVS380.

Are you following the instructions in inst380.txt?

I need to fix them if it's confusing (you're the first
person to give installation feedback).

But I'm not 100% sure you're actually following them,
because you're using quite different commands. But
some of it looks like you are following it.

BFN. Paul.

time2ipl

2008-07-12 04:23:11 UTC

Hi, Paul -

Post by kerravon86
Don't worry about BCMODE if you don't know what AMODE is.
I assumed you were downloading MVS/380 because you liked
the idea of 31-bit addressing. You want it for the C
compiler or tools, do you?

Yeah; specifically, the GNU C/C++ compiler. When I saw the note
stating that gcc couldn't function on 24 bit systems, I became <very>
interested in 31 bit systems.

It is true that gcc can't successfully compile a program on stock, 24
bit, MVS 3.8j, right?

Post by kerravon86
In brief, MVS/380 has the ability to use 2 GB of memory
instead of the normal 16 MB. But depending on what
you're doing, that may not be useful to you.

Aside from the GNU C/C++ compiler, I can't think of any reason why I
would need more than 16Mb. As using C under MVS is something I've
been itching to try for some time now, that alone is worth doing this.

Post by kerravon86

Post by time2ipl

Post by kerravon86
So maybe both of these changes should be incorporated
soon and a new version released.
Would you like to get involved in releasing the
Hercules/380 executables?

Sure. Just remember, my knowledge of mainframe systems is limited.

That's fine. It's actually compiling the stupid DLL
under Windows that I never figured out how to do
properly. I got stuck on the instruction "then fix
the broken Makefile".

There, I can help; as much as I hate to admit it in some respects,
I've been programming Windows since 1988, and while I haven't had any
new products for that platform for a little over 5 years, at least
some of the contracting and consulting we/I do still involves fixing
esoteric Windows systems, problems, etc.

Post by kerravon86
... And I don't have Linux installed either.

I solved that problem with (you guessed it) virtual machines on top of
Linux; it's just as easy (easier, actually) to run Linux on top of
Windows, in take-your-pick-of-products.

Post by kerravon86
... Not sure if normal Hercules is distributed as a Linux
executable, but if it is, then so should Hercules/380 ideally.

Not much Linux software is distributed in binary-only format;
distributing binary-only code, drivers, etc. is pretty vigorously
discouraged. By itself that wouldn't be too bad; however, there are a
few major Linux "flavors", none of which use the same build system, or
agree WRT what should go where, even though there is a "Filesystem
Hierarchy Standard". For example, some put executables in
/usr/local/bin, while others put executables in /usr/bin; still others
prefer /opt. This isn't near as bad as it sounds, though; by and
large, the GNU "automake" tools can be used to accommodate just about
every system out there.

That issue is in part why how I built Hercules didn't make sense; I
assumed that you realized I was building it from an SRPM (.src.rpm) -
a common setup for building one of those is, you have, on your system,
a directory structure that looks like this:

/usr/src/redhat
|-- BUILD
|-- LOGS
|-- RPMS
| |-- i386
| |-- i486
| |-- i586
| |-- i686
| |-- noarch
| `-- x86_64
|-- SOURCES
|-- SPECS
`-- SRPMS

In the case of the Hecules SRPM, it continues on to look like this:

/usr/src/redhat
|-- BUILD
`-- hercules-3.05
|-- assist.c
...
|-- cpu.c
...
|-- Makefile
...
...
|-- SOURCES
| |-- hercules.cnf
| |-- hercules-run
| |-- hercules-3.05-open.patch
| |-- hercules-3.05.tar.gz
| `-- hercules-3.05-save-network-state.patch
|-- SPECS
`-- hercules.spec
`-- SRPMS

The build preparation steps (path application, execution of the
configure script, etc.) are carried out, in this case, in
/usr/src/redhat/BUILD/hercules-3.05. The build is performed in a
directory who's location is controlled by the BuildRoot directive in
the .spec file for the package (it's usually a subdirectory of
/var/tmp). And, when an RPM is built, it's installed into a temporary
directory, too, with "%{__make} install DESTDIR=%{buildroot}".

Post by kerravon86
And you directed this to install into /mvs380, right?

Right.

Post by kerravon86

Post by time2ipl
When it completed, I changed my working directory to

be /usr/src/HERCULES.

Post by time2ipl
cd /usr/src/HERCULES
I had already "got" TK3SU1.zip, fixpack1.zip - just for reference, I
wget 'http://www.softlib.org/TK4Beta/TK3SU1.zip'
wget 'http://www.softlib.org/TK4Beta/fixpack1.zip'
unzip TK3SU1.zip -d TK3SU1/
unzip mvs380-0_4.zip -d mvs380/

These things are meant to overwrite each other in the
same directory, not be installed into separate
directories.

Ok. That's what I wasn't sure about. Each file in mvs380-0_4.zip is
intended to replace the file in the Toolkit installation with which it
corresponds, then.

Post by kerravon86
But I'm not 100% sure you're actually following them,
because you're using quite different commands. But
some of it looks like you are following it.

That's ok; it seems due mostly to the screwy build procedure imposed
by RedHat / Fedora. Yeah, I was following them; when it didn't work
properly and I went back and tried to make sure everything was where
it ought to be, the instructions were a bit confusing, but more
because they didn't correlate to the steps one has to follow when
building an RPM. Which is neither your fault, nor your problem.

It's a catch-22; if you don't install software on a RedHat/Fedora
system from RPM packages, you end up with all sorts of strange
dependency problems. And packages, etc., getting overwritten. And so
on. It's just bad news.

As you've probably surmised, they (RPM packages) can be less than a
joy to deal with in their own right, however.

How does this sound - now that I'm certain as to what goes where
(unless you tell me my assumption above is incorrect), I'll try it
again, from the top, tomorrow morning.

As far as the instructions go, I would suggest holding off on them
until then, at which point I should be able to say with some degree of
certainty that it either works or doesn't. Sound OK?

In the meantime, if you want to go ahead and email me what you have
v/v the Windows build, I'll take a look at that.

Take it easy; I'm off to go look at the inside of my eyelids for a
little while.

- Larry

halfmeg

2008-07-12 05:14:02 UTC

Post by time2ipl

Post by kerravon86
I assumed you were downloading MVS/380 because you liked
the idea of 31-bit addressing. You want it for the C
compiler or tools, do you?

Yeah; specifically, the GNU C/C++ compiler. When I saw the note
stating that gcc couldn't function on 24 bit systems, I became
<very> interested in 31 bit systems.

It functions on 24 bit systems. VM/370 is able to compile all the
modules as it has slightly more memory to allow those few which get
stuck in MVS 3.8j.

It is the C compiler only. The C++ frontend has never been attempted
to my knowledge. ( I should know )

Post by time2ipl
It is true that gcc can't successfully compile a program on stock,
24 bit, MVS 3.8j, right?

Wrong, there are only a few modules of GCC which can't be compiled in
the stock TK3 system due to the memory constraints.

Post by time2ipl

Post by kerravon86
In brief, MVS/380 has the ability to use 2 GB of memory
instead of the normal 16 MB. But depending on what
you're doing, that may not be useful to you.

Aside from the GNU C/C++ compiler, I can't think of any reason why I
would need more than 16Mb. As using C under MVS is something I've
been itching to try for some time now, that alone is worth doing this.

The TK3 shadow update has a beta version of GCCMVS included in it
IIRC. The release wasn't ready when I cut the shadow update.

Post by time2ipl
<snip bunch of stuff concerning rpm and structure, aargh >

Post by kerravon86
And you directed this to install into /mvs380, right?

Right.

Although the source, binaries for Linux, Windows, & MAC seem to be
available at hercules-390.org, it might be better to checkout the
source from CVS or download the source tarball from ivansoftware.org
to get the more recent modifications to Hercules. ( Paul's mods are
not included in official Hercules and his mods are against the last
offical release 3.05 ( AFAIK ) from June 2007).

Post by time2ipl
<snip>

I had posted on the hercules-390 main forum concerning a windows build
with the dyn75.c, dyn75.dll included but have recieved no response.
It had been previously done with an earlier hercules version but was
only distributed to the TK4 beta test group.

Phil - wondering if MSVC build environment will take over yet another
machine

kerravon86

2008-07-12 05:38:14 UTC

Post by halfmeg

Post by time2ipl

Post by kerravon86
I assumed you were downloading MVS/380 because you liked
the idea of 31-bit addressing. You want it for the C
compiler or tools, do you?

Yeah; specifically, the GNU C/C++ compiler. When I saw the note
stating that gcc couldn't function on 24 bit systems, I became
<very> interested in 31 bit systems.

It functions on 24 bit systems. VM/370 is able to compile all the
modules as it has slightly more memory to allow those few which get
stuck in MVS 3.8j.

Only if you switch off optimization.

Post by halfmeg
It is the C compiler only. The C++ frontend has never been

attempted

Post by halfmeg
to my knowledge. ( I should know )

Right. Not C++ library either.

Post by halfmeg

Post by time2ipl
It is true that gcc can't successfully compile a program on stock,
24 bit, MVS 3.8j, right?

Wrong, there are only a few modules of GCC which can't be compiled in
the stock TK3 system due to the memory constraints.

Actually there's heaps unless you reduce the CSA and
switch off optimization.

Post by halfmeg

Post by time2ipl

Post by kerravon86
In brief, MVS/380 has the ability to use 2 GB of memory
instead of the normal 16 MB. But depending on what
you're doing, that may not be useful to you.

Aside from the GNU C/C++ compiler, I can't think of any reason why I
would need more than 16Mb. As using C under MVS is something I've
been itching to try for some time now, that alone is worth doing this.

The TK3 shadow update has a beta version of GCCMVS included in it
IIRC. The release wasn't ready when I cut the shadow update.

Right. That was only a beta.

Post by halfmeg

Post by time2ipl
<snip bunch of stuff concerning rpm and structure, aargh >

Post by kerravon86
And you directed this to install into /mvs380, right?

Right.

Although the source, binaries for Linux, Windows, & MAC seem to be
available at hercules-390.org, it might be better to checkout the
source from CVS or download the source tarball from ivansoftware.org
to get the more recent modifications to Hercules. ( Paul's mods are
not included in official Hercules and his mods are against the last
offical release 3.05 ( AFAIK ) from June 2007).

Correct. The one feature that I do want that 3.05
doesn't have isn't in the beta.

BFN. Paul.

kerravon86

2008-07-12 05:26:47 UTC

Post by time2ipl
Hi, Paul -

Post by kerravon86
Don't worry about BCMODE if you don't know what AMODE is.
I assumed you were downloading MVS/380 because you liked
the idea of 31-bit addressing. You want it for the C
compiler or tools, do you?

Yeah; specifically, the GNU C/C++ compiler. When I saw the note
stating that gcc couldn't function on 24 bit systems, I became

<very>

Post by time2ipl
interested in 31 bit systems.
It is true that gcc can't successfully compile a program on stock, 24
bit, MVS 3.8j, right?

No, that is not correct. In fact, TK3SU1 comes with
a very old version of GCCMVS on it already.

However, the problem is that it can't compile really
large programs, especially if you switch optimization
on. There are a variety of ways of overcoming this
problem:

1. Compiling on VM/370 gives more memory than MVS 3.8j,
which may be sufficient for your purpose.
(con - max memory not enough for very large programs).

2. Cross-compiling on the PC gives you all the memory
you need.
(con - compiler known in the past to generate bad
code due to ASCII/EBCDIC differences)

3. Compiling on z/OS gives you all the memory you
need.
(con - expensive commercial system)

4. Compiling on MVS/380 gives you all the memory you
need.
(con - can only one run compile at a time)

However, if you had a desire to run multiple
simultaneous compiles of smallish programs, then
MVS/370 is actually superior to MVS/380.
MVS/380 gains you nothing at all.

The GCCMVS source code itself is amongst the code
that is too big for MVS/370, so it can't
self-compile under MVS/370. Interestingly, VM/370
has sufficient memory to self-compile an unoptimized
version of GCCCMS.

So, MVS/370 is a fully supported platform for GCCMVS.
Although if you want the executable, you'll have to
compile it (actually just assemble it) yourself, as
I only provide the 31-bit version as part of MVS/380.

Post by time2ipl

Post by kerravon86
In brief, MVS/380 has the ability to use 2 GB of memory
instead of the normal 16 MB. But depending on what
you're doing, that may not be useful to you.

Aside from the GNU C/C++ compiler, I can't think of any reason why I
would need more than 16Mb. As using C under MVS is something I've
been itching to try for some time now, that alone is worth doing this.

Being able to run 31-bit is something you should be
itching to try too. :-) It wasn't even a concept less
than a year ago.

Post by time2ipl
There, I can help; as much as I hate to admit it in some respects,
I've been programming Windows since 1988, and while I haven't had any
new products for that platform for a little over 5 years, at least
some of the contracting and consulting we/I do still involves fixing
esoteric Windows systems, problems, etc.

Ok, great.

Post by time2ipl
That issue is in part why how I built Hercules didn't make sense; I
assumed that you realized I was building it from an SRPM

(.src.rpm) -

No, never used that. unzip is more my league.

Post by time2ipl
Ok. That's what I wasn't sure about. Each file in mvs380-0_4.zip is
intended to replace the file in the Toolkit installation with which it
corresponds, then.

Yes. Just unzip in order of oldest to latest and allow
overwrite and it will be fine. You can't do it the
other way around because you can't tell the TK3
install to not overwrite.

Post by time2ipl

Post by kerravon86
But I'm not 100% sure you're actually following them,
because you're using quite different commands. But
some of it looks like you are following it.

That's ok; it seems due mostly to the screwy build procedure imposed
by RedHat / Fedora. Yeah, I was following them; when it didn't work
properly

You didn't tell me what went wrong here.

Post by time2ipl
How does this sound - now that I'm certain as to what goes where
(unless you tell me my assumption above is incorrect), I'll try it
again, from the top, tomorrow morning.

Sounds good to me.

Post by time2ipl
As far as the instructions go, I would suggest holding off on them
until then, at which point I should be able to say with some degree of
certainty that it either works or doesn't. Sound OK?

Yep.

Post by time2ipl
In the meantime, if you want to go ahead and email me what you have
v/v the Windows build, I'll take a look at that.

Easier if you email me first. mutazilah at ...
... gmail.com as I rarely use the email address that
shows up here.

I haven't completed the latest Hercules mods yet, but
hopefully today or tomorrow.

BFN. Paul.

Gerhard Postpischil

2008-07-14 03:29:36 UTC

Post by kerravon86
BTW, back in the mainframe days was there ever the
ability to access a normal modem so that you could
dial a bulletin board and download data?

The hardware capability was there, provided you had a dialing
adapter on your line, but you still needed to write the software.

Post by kerravon86
Also, what would be required for a graphics terminal
on MVS 3.8j running a web browser?

Not sure what you want - using an MVS attached device to get to
the internet and browse, or use an external device to access web
pages hosted on MVS? For full graphics, you'd need a decent
terminal emulator (I use Seagull's BlueZone). Basic tcp/ip code
may materialize in the near future?

I'm back from vacation, but still need a few days to recover
(1300 e-mail messages plus 1204 spam; snail-mail, etc.)

Gerhard Postpischil
Bradford, VT

kerravon86

2008-07-14 11:41:27 UTC

Post by Gerhard Postpischil

Post by kerravon86
BTW, back in the mainframe days was there ever the
ability to access a normal modem so that you could
dial a bulletin board and download data?

The hardware capability was there, provided you had a dialing
adapter on your line, but you still needed to write the software.

It was a bit frustrating having a PC connected to
the mainframe doing terminal emulation (around
1989), but not being able to run a batch job that
could do an ATZ to provide any sort of link to the
outside world no matter how slow. I could visibly
see the links but couldn't get them to do what I
wanted. I didn't believe that the mainframe was
able to talk to a remote mainframe but couldn't
get a 300 bps link up and running.

Post by Gerhard Postpischil

Post by kerravon86
Also, what would be required for a graphics terminal
on MVS 3.8j running a web browser?

Not sure what you want - using an MVS attached device to get to
the internet and browse

Yes, this one. At one place I worked I scored a 3278
or something that was a graphics terminal. I think it
was barely reasonable if it was connected to the
channel or something like that.

If you have a graphics terminal connected to a channel,
does that mean it would be capable of doing web
browsing assuming the underlying TCP/IP was already
in place?

Or is there something limiting about those IBM
graphics terminals that would prevent that?

Post by Gerhard Postpischil
I'm back from vacation, but still need a few days to recover
(1300 e-mail messages plus 1204 spam; snail-mail, etc.)

Wow!

BFN. Paul.

Gerhard Postpischil

2008-07-14 15:32:30 UTC

Post by kerravon86
It was a bit frustrating having a PC connected to
the mainframe doing terminal emulation (around
1989), but not being able to run a batch job that
could do an ATZ to provide any sort of link to the
outside world no matter how slow. I could visibly
see the links but couldn't get them to do what I
wanted. I didn't believe that the mainframe was
able to talk to a remote mainframe but couldn't
get a 300 bps link up and running.

By 1989 you should have been using 9600 bps, anyway. If you're
willing to roll your own, you could use EXCP to drive a
start-stop line (TTY, TWX, 1050, 2740, 2741, etc.), or BTAM or
VTAM to drive a 2780 or 3780 compatible interface. If you
defined the line as permanently connected and used a modem with
the AT command set and feedback, you could do just about
anything you wanted. Software support for some
mainframe/mainframe communication (HASP & JES2 NJE) has been
available since the seventies.

Post by kerravon86
Yes, this one. At one place I worked I scored a 3278
or something that was a graphics terminal. I think it
was barely reasonable if it was connected to the
channel or something like that.

The 3279 provided 32 lines of 80 characters, and limited
graphics (with proper software, could do vector graphics) in
seven colors. The 3179 dropped the graphics capability. The 2250
and 3250 had vector graphics and other neat features, but only
one color.

Post by kerravon86
If you have a graphics terminal connected to a channel,
does that mean it would be capable of doing web
browsing assuming the underlying TCP/IP was already
in place?

You need two links - one for the terminal, and one for the
TCP/IP connection (otherwise you'd be using your terminal
emulator as a browser and don't need Hercules?). This means
writing or adapting a browser to run under MVS.

Post by kerravon86
Or is there something limiting about those IBM
graphics terminals that would prevent that?

With a decent 3279 emulator, you can draw boxes, provide
characters with foreground or background color, but you could
not produce text with multiple font sizes (easily), nor (many)
different styles. The 3279 provides triple-plane capability,
allowing you to define an arbitrary pixel pattern in one
character position in the red, blue, and green plane
(combinations produce white, cyan, blue, yellow, green, magenta,
red, and black). You're allowed multiple symbols sets (depending
on memory), each with a range from x'40' to x'FE'. For example,
I have a demo page where one value produces a solid white box,
another a solid red box, another a solid blue box, and the
fourth a blue box with a white star in in. By writing the
appropriate text, I can draw a US flag. Your browser software
would have to decide what features to implement, and then
convert the web page data to "text" creating a reasonable
facsimile. You won't get 100%, since the total number of pixel
combinations you need will be smaller than what you can shoehorn
into your code.....

IBM also made a 3270PC, but I don't recall the technical specs
for the display capabilities (box outlines around fields;
characters with foreground and background colors, plus ?)

Gerhard Postpischil
Bradford, VT

peter_flass

2008-07-15 11:13:07 UTC

If the job was doing that, it wouldn't be strictly a batch job. You'd
probably just write it as a CICS transaction.

Post by Gerhard Postpischil

Post by kerravon86
It was a bit frustrating having a PC connected to
the mainframe doing terminal emulation (around
1989), but not being able to run a batch job that
could do an ATZ to provide any sort of link to the
outside world no matter how slow. I could visibly
see the links but couldn't get them to do what I
wanted. I didn't believe that the mainframe was
able to talk to a remote mainframe but couldn't
get a 300 bps link up and running.

By 1989 you should have been using 9600 bps, anyway. If you're
willing to roll your own, you could use EXCP to drive a
start-stop line (TTY, TWX, 1050, 2740, 2741, etc.), or BTAM or
VTAM to drive a 2780 or 3780 compatible interface. If you
defined the line as permanently connected and used a modem with
the AT command set and feedback, you could do just about
anything you wanted. Software support for some
mainframe/mainframe communication (HASP & JES2 NJE) has been
available since the seventies.

Post by kerravon86
Yes, this one. At one place I worked I scored a 3278
or something that was a graphics terminal. I think it
was barely reasonable if it was connected to the
channel or something like that.

The 3279 provided 32 lines of 80 characters, and limited
graphics (with proper software, could do vector graphics) in
seven colors. The 3179 dropped the graphics capability. The 2250
and 3250 had vector graphics and other neat features, but only
one color.

Post by kerravon86
If you have a graphics terminal connected to a channel,
does that mean it would be capable of doing web
browsing assuming the underlying TCP/IP was already
in place?

You need two links - one for the terminal, and one for the
TCP/IP connection (otherwise you'd be using your terminal
emulator as a browser and don't need Hercules?). This means
writing or adapting a browser to run under MVS.

Post by kerravon86
Or is there something limiting about those IBM
graphics terminals that would prevent that?

With a decent 3279 emulator, you can draw boxes, provide
characters with foreground or background color, but you could
not produce text with multiple font sizes (easily), nor (many)
different styles. The 3279 provides triple-plane capability,
allowing you to define an arbitrary pixel pattern in one
character position in the red, blue, and green plane
(combinations produce white, cyan, blue, yellow, green, magenta,
red, and black). You're allowed multiple symbols sets (depending
on memory), each with a range from x'40' to x'FE'. For example,
I have a demo page where one value produces a solid white box,
another a solid red box, another a solid blue box, and the
fourth a blue box with a white star in in. By writing the
appropriate text, I can draw a US flag. Your browser software
would have to decide what features to implement, and then
convert the web page data to "text" creating a reasonable
facsimile. You won't get 100%, since the total number of pixel
combinations you need will be smaller than what you can shoehorn
into your code.....
IBM also made a 3270PC, but I don't recall the technical specs
for the display capabilities (box outlines around fields;
characters with foreground and background colors, plus ?)
Gerhard Postpischil
Bradford, VT

Gerhard Postpischil

2008-07-15 18:53:45 UTC

Post by peter_flass
If the job was doing that, it wouldn't be strictly a batch job. You'd
probably just write it as a CICS transaction.

Could you be any less cryptic? I have no idea what that refers to.

Gerhard Postpischil
Bradford, VT

antoniofilgueirajunior

2008-09-02 16:10:04 UTC

Hy,
Reding your post and I facing a problem with comunication with my PC
running windows(10.10.0.234) and runnning the Rumba3270 conected with
server(10.10.0.220:3270) with my Hercules running in another PC
running Linux Ubuntu.

I can conect a works weel but I cant't make transfer file.

basicly i want transfer file from my PC to my user MVS(i.e P390 or
IBMUSER) this files that I want transfer are some files from CBTTapes.

Before this my Adventure in Linux i was runing Hercules on a only PC
under Window(HercGui) and I can do that, but now, in difrente PC I'm
with communication problem.

Any Help?
Do I need add any configuration on configuration file of MVS? like
TCPIP.CONFIG?

thans a lot

Post by Dave Wade
Larry,
There has never been a real functioning TCP/IP stack in MVS3.8J. What
Jason did was to steal op code "75" and use it to pass TCP/IP

socket

Post by Dave Wade
calls in and out of MVS. So there was basically a DLL that was

loaded

Post by Dave Wade
with Hercules that handled OpCode 75 and mapped it onto host socket
calls. allowing MVS to use the IP stack on the PC. Unfortunatly he
copyrighted the code, and I can't find the redistribution

restrictions

Post by Dave Wade
so I can't send you a copy. (In general I think you were/are NOT allowed
to re-distribute most of Jason's stuff)
CTC and LCS devices work at a lower level and so require a good
knowledge of IP (and MAC I think for LCS) so I think using them would
require a complete network stack in MVS3.8J, or would require

extensive

Post by Dave Wade
mods to Hercules. Depending on how I wanted to talk I think I might do:-
1) Hi-jack a 3270 session in the same way that ind$file does.
2) Use sockets to the reader/printer => this is what NETCAT does
3) Use the bi-sync to IP line driver like the various RJE programs do.
This could also be used in a similar way to "1" to hack 3270 code.
I might also use the DIAG8 code in Hercules to pass command results back
and forth in combination with the above...
So little time so much to do....
Dave

Post by time2ipl
Hi, all -
I've been trying to figure out how to get MVS 3.8 (the same one
everyone else seems to be using) to "talk to" the Linux host that
Hercules is running on.
Networking / TCP/IP support isn't the problem. What I'm in need of is
either an application (preferably) or an API (at a minimum) that will
let me communicate across either a CTC adapter or LCS adapter to the
host that Hercules is running on. What I'm missing, is a program that
can talk to the outside world through that interface.
Just as a side note: I'm not yet familiar with either CTC or LCS
adapters. I've done a lot of communications programming, but the bulk
of the work I've done with mainframes has been at the protocol and
application levels.
Is there, currently, a working TCP/IP protocol stack for MVS 3.8; and,
if there is, could someone point me to it? And to whatever apps there
are that utilize it?
After my first web search, this seemed like it'd be a pretty easy nut
to crack; I found numerous references to "Jason Winter", his FTP
server, and "the jcc compiler". Unfortunately, all of them seem to
have vanished; apparently thanks to (at least in part) a company
called "Dignus Systems".
If TCP/IP isn't an option, can someone point me to where I could begin
trying to cook up an alternate way to "talk to" the MVS system? I've
seen "netcat" work, reliably, so I know it's possible to get data from
point A to point B. I'm just not clear on how... Nor am I clear how
the CTC and/or LCS adapters play into the whole picture. But,
hopefully, someone - or several someones - can help me with

that...

Post by Dave Wade

Post by time2ipl
Thanks in advance,
Larry

Thomas David Rivers

2008-06-30 13:25:22 UTC

Post by time2ipl
After my first web search, this seemed like it'd be a pretty easy nut
to crack; I found numerous references to "Jason Winter", his FTP
server, and "the jcc compiler". Unfortunately, all of them seem to
have vanished; apparently thanks to (at least in part) a company
called "Dignus Systems".

Larry,

I've recently posted a note about this... but I want to
reiterate. Dignus was not the "cause" of any apparent vanishing.

To be absolutely clear on what happened:

Jason Winter misappropriated our code in production of his product.

After some discussion involving international copyright lawyers, Jason
signed a legal document indicating he had misappropriated our code... and
giving us the right to make a posting like this one. Jason agreed to
remove the stolen code.

Jason removed the code and re-issued his products, without the
offending code.

About a year after that, Jason disappeared. I dont know why or how.

I just want to be clear, we were not the "cause" of his disappearance,
nor were we the cause of the problem. Jason stole our code and
we acted on it. Jason later disappeared... we don't know why.

I'm just a little disappointed when the victim is cast as the culprit.

- Dave Rivers -

--
rivers-Glb8JK3v8o7QT0dZR+***@public.gmane.org Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

rfochtman

2008-06-30 16:16:50 UTC

-------------------<snip>--------------
I'm just a little disappointed when the victim is cast as the culprit.
--------------------<unsnip>-----------------
I'm sure that only happened because of a lack of information, not
malicious intent.

Rick

cedarlakebuzzards

2008-07-07 07:17:24 UTC

Hi
I am assuming you want real time communications to take place and not
just file transfer. This might sound like it is out of left field but
it worked fine for production applications at a previous employer.
The technique is called "screen scrapping".

The mainframe application sends a screen to a 3270. The 3270 was
really an emulator running on the PC. The "3270 emulator" was able to
take data from the screen and process it. To return data, the
emulator "typed" data into the screen and sent data back to the mainframe.

This technique required no special software on MVS. Hercules will
handle the communication to TN3270. The TN3270 emulator running on
the PC can communicate with Hercules via TCP/IP. TN3270 should allow
API to access the screens data fields.

Ed

Post by time2ipl
Hi, all -
I've been trying to figure out how to get MVS 3.8 (the same one
everyone else seems to be using) to "talk to" the Linux host that
Hercules is running on.
Networking / TCP/IP support isn't the problem. What I'm in need of is
either an application (preferably) or an API (at a minimum) that will
let me communicate across either a CTC adapter or LCS adapter to the
host that Hercules is running on. What I'm missing, is a program that
can talk to the outside world through that interface.
Just as a side note: I'm not yet familiar with either CTC or LCS
adapters. I've done a lot of communications programming, but the bulk
of the work I've done with mainframes has been at the protocol and
application levels.
Is there, currently, a working TCP/IP protocol stack for MVS 3.8; and,
if there is, could someone point me to it? And to whatever apps there
are that utilize it?
After my first web search, this seemed like it'd be a pretty easy nut
to crack; I found numerous references to "Jason Winter", his FTP
server, and "the jcc compiler". Unfortunately, all of them seem to
have vanished; apparently thanks to (at least in part) a company
called "Dignus Systems".
If TCP/IP isn't an option, can someone point me to where I could begin
trying to cook up an alternate way to "talk to" the MVS system? I've
seen "netcat" work, reliably, so I know it's possible to get data from
point A to point B. I'm just not clear on how... Nor am I clear how
the CTC and/or LCS adapters play into the whole picture. But,
hopefully, someone - or several someones - can help me with that...
Thanks in advance,
Larry

Dave Wade

2008-07-07 07:22:14 UTC

Ed,

Having written a few screen scraping applications I would say its not a way
I would go these days. Getting the timing right is such a drag. I guess it
would be easier with Hercules because usually you have a dedicated
mainframe..

Dave Wade G4UGM

Illegitimi Non Carborundum

-----Original Message-----
From: H390-MVS-***@public.gmane.org [mailto:H390-MVS-***@public.gmane.org] On Behalf
Of cedarlakebuzzards
Sent: 07 July 2008 08:17
To: H390-MVS-***@public.gmane.org
Subject: [H390-MVS] Re: Communication Between MVS in Hercules && Herc's
Linux, etc. Host: How?

Hi
I am assuming you want real time communications to take place and not
just file transfer. This might sound like it is out of left field but
it worked fine for production applications at a previous employer.
The technique is called "screen scrapping".

The mainframe application sends a screen to a 3270. The 3270 was
really an emulator running on the PC. The "3270 emulator" was able to
take data from the screen and process it. To return data, the
emulator "typed" data into the screen and sent data back to the mainframe.

This technique required no special software on MVS. Hercules will
handle the communication to TN3270. The TN3270 emulator running on
the PC can communicate with Hercules via TCP/IP. TN3270 should allow
API to access the screens data fields.

Ed

Post by time2ipl
Hi, all -
I've been trying to figure out how to get MVS 3.8 (the same one
everyone else seems to be using) to "talk to" the Linux host that
Hercules is running on.
Networking / TCP/IP support isn't the problem. What I'm in need of is
either an application (preferably) or an API (at a minimum) that will
let me communicate across either a CTC adapter or LCS adapter to the
host that Hercules is running on. What I'm missing, is a program that
can talk to the outside world through that interface.
Just as a side note: I'm not yet familiar with either CTC or LCS
adapters. I've done a lot of communications programming, but the bulk
of the work I've done with mainframes has been at the protocol and
application levels.
Is there, currently, a working TCP/IP protocol stack for MVS 3.8; and,
if there is, could someone point me to it? And to whatever apps there
are that utilize it?
After my first web search, this seemed like it'd be a pretty easy nut
to crack; I found numerous references to "Jason Winter", his FTP
server, and "the jcc compiler". Unfortunately, all of them seem to
have vanished; apparently thanks to (at least in part) a company
called "Dignus Systems".
If TCP/IP isn't an option, can someone point me to where I could begin
trying to cook up an alternate way to "talk to" the MVS system? I've
seen "netcat" work, reliably, so I know it's possible to get data from
point A to point B. I'm just not clear on how... Nor am I clear how
the CTC and/or LCS adapters play into the whole picture. But,
hopefully, someone - or several someones - can help me with that...
Thanks in advance,
Larry

Davide Grandi

2008-07-07 12:42:52 UTC

Post by Dave Wade
Having written a few screen scraping applications I would say
its not a way I would go these days. Getting the timing right
is such a drag.

Working for an employer that makes a living for nearly one hundred people with mainframe and as/400 screen scraping I would say ... it depends B-)

With a not too complex model of how 3270 or 5250 works you CAN use screen scraping to transfer data from a green screen to a client program, a web app or even a web service.

We use screen scraping for some thousand of users of our ERP (and "my" 3 customers accounts for 900 users of THEIR erp) and any reasonable host screen can be captured, identified and converted to XML-HTML-what else.

More : 10 years ago they remodeled the mainframe COBOL program in order to "render" the BMS maps ALSO in XML so they could run the ERP in AIX-Windows & Linux COBOL without screen scraping (difficult under VT-xyz telnet emulation) but with the same front end (now XHTML).

It works, and now at my employer the COBOL programmer have only one main codebase (for MVS) and five target platform (and a handful of db).

Best regards,

Davide Grandi
--
Ing. Davide Grandi
davide.grandi-dP4/***@public.gmane.org

cedarlakebuzzards

2008-07-08 10:56:17 UTC

Returning to Larry's original question, comments were made about why
screen scraping should not be used and I fully agree. Today, TCP/IP
stacks are available on the majority of platforms and things like
screen scraping would be a less than optimal solution.

Given the technology of the 1970's, there was no TCP/IP stack under
MVS 38j. SNA was the only way to communicate with devices like 3270s.
We were connecting mainframes to MINI computers (DEC, Prime, Tandem,
etc) running 3270 emulators. It was not very elegant but it worked.

Larry, good luck to you

Ed

Post by Davide Grandi

Post by Dave Wade
Having written a few screen scraping applications I would say
its not a way I would go these days. Getting the timing right
is such a drag.

Working for an employer that makes a living for nearly one hundred

people with mainframe and as/400 screen scraping I would say ... it
depends B-)

Post by Davide Grandi
With a not too complex model of how 3270 or 5250 works you CAN use

screen scraping to transfer data from a green screen to a client
program, a web app or even a web service.

Post by Davide Grandi
We use screen scraping for some thousand of users of our ERP (and

"my" 3 customers accounts for 900 users of THEIR erp) and any
reasonable host screen can be captured, identified and converted to
XML-HTML-what else.

Post by Davide Grandi
More : 10 years ago they remodeled the mainframe COBOL program in

order to "render" the BMS maps ALSO in XML so they could run the ERP
in AIX-Windows & Linux COBOL without screen scraping (difficult under
VT-xyz telnet emulation) but with the same front end (now XHTML).

Post by Davide Grandi
It works, and now at my employer the COBOL programmer have only one

main codebase (for MVS) and five target platform (and a handful of db).

Post by Davide Grandi
Best regards,
Davide Grandi
--
Ing. Davide Grandi

Dave Wade

2008-07-08 12:56:44 UTC

Actually one thought. If you going to screen scrape then it may be
benificial to alter the host pogram, if its accessible. For example in a
screen based application, simply putting a screen name in a constant
location on the screen can make scraping so much simpler...

.. I guess ind$file is a good example of this approach...

Post by cedarlakebuzzards
Returning to Larry's original question, comments were made about why
screen scraping should not be used and I fully agree. Today, TCP/IP
stacks are available on the majority of platforms and things like
screen scraping would be a less than optimal solution.
Given the technology of the 1970's, there was no TCP/IP stack under
MVS 38j. SNA was the only way to communicate with devices like 3270s.
We were connecting mainframes to MINI computers (DEC, Prime, Tandem,
etc) running 3270 emulators. It was not very elegant but it worked.
Larry, good luck to you
Ed

Post by Davide Grandi

Post by Dave Wade
Having written a few screen scraping applications I would say
its not a way I would go these days. Getting the timing right
is such a drag.

Working for an employer that makes a living for nearly one hundred

people with mainframe and as/400 screen scraping I would say ... it
depends B-)

Post by Davide Grandi
With a not too complex model of how 3270 or 5250 works you CAN use

screen scraping to transfer data from a green screen to a client
program, a web app or even a web service.

Post by Davide Grandi
We use screen scraping for some thousand of users of our ERP (and

"my" 3 customers accounts for 900 users of THEIR erp) and any
reasonable host screen can be captured, identified and converted to
XML-HTML-what else.

Post by Davide Grandi
More : 10 years ago they remodeled the mainframe COBOL program in

order to "render" the BMS maps ALSO in XML so they could run the ERP
in AIX-Windows & Linux COBOL without screen scraping (difficult under
VT-xyz telnet emulation) but with the same front end (now XHTML).

Post by Davide Grandi
It works, and now at my employer the COBOL programmer have only one

main codebase (for MVS) and five target platform (and a handful of db).

Post by Davide Grandi
Best regards,
Davide Grandi
--
Ing. Davide Grandi

Phil Dickinson

2008-07-08 21:15:24 UTC

Even in the 70's there were more elegant ways to connect a mainframe
to a mini.... does anyone remember the 3790 series of minis from IBM?
They connected via SNA using an LU Type Zero session. Programs and
data could be transfered from MVS and data could be retrieved, all
using SNA. Even with the limited SNA in MVS 3.8J. It just worked.

The biggest problem with the mini's mentioned (DEC, Prime, Tandem),
was the woeful implementation of SNA. They mostly thought it only
worked for 3270's so that's what they emulated. Some did RJE devices
too, but typically with a tiny subset of the protocols that were
really needed.

It got better when a couple of start up companis started offering SNA
products for some of these mini's. A very good product was available
for Tandem for example.

phil.

Post by cedarlakebuzzards
Returning to Larry's original question, comments were made about why
screen scraping should not be used and I fully agree. Today, TCP/IP
stacks are available on the majority of platforms and things like
screen scraping would be a less than optimal solution.
Given the technology of the 1970's, there was no TCP/IP stack under
MVS 38j. SNA was the only way to communicate with devices like 3270s.
We were connecting mainframes to MINI computers (DEC, Prime, Tandem,
etc) running 3270 emulators. It was not very elegant but it worked.
Larry, good luck to you
Ed

Post by Davide Grandi

Post by Dave Wade
Having written a few screen scraping applications I would say
its not a way I would go these days. Getting the timing right
is such a drag.

Working for an employer that makes a living for nearly one hundred

people with mainframe and as/400 screen scraping I would say ... it
depends B-)

Post by Davide Grandi
With a not too complex model of how 3270 or 5250 works you CAN use

screen scraping to transfer data from a green screen to a client
program, a web app or even a web service.

Post by Davide Grandi
We use screen scraping for some thousand of users of our ERP (and

"my" 3 customers accounts for 900 users of THEIR erp) and any
reasonable host screen can be captured, identified and converted to
XML-HTML-what else.

Post by Davide Grandi
More : 10 years ago they remodeled the mainframe COBOL program in

order to "render" the BMS maps ALSO in XML so they could run the ERP
in AIX-Windows & Linux COBOL without screen scraping (difficult under
VT-xyz telnet emulation) but with the same front end (now XHTML).

Post by Davide Grandi
It works, and now at my employer the COBOL programmer have only one

main codebase (for MVS) and five target platform (and a handful of db).

Post by Davide Grandi
Best regards,
Davide Grandi
--
Ing. Davide Grandi

Gerhard Postpischil

2008-07-14 03:17:48 UTC

Post by cedarlakebuzzards
Given the technology of the 1970's, there was no TCP/IP stack under
MVS 38j. SNA was the only way to communicate with devices like 3270s.

Just got back from vacation, and feel the need to insert a
little pedantry here. We all know that all general statements
are false <g>, and the above is a good example. In the seventies
and eighties I used VTAM to communicate with some SNA devices,
however, I also used BTAM (BSC2) and EXCP (local non-SNA) to
communicate with 3270 family devices. And I also had a hybrid
program that used EXCP for I/O, but the BTAM attention routine
to process responses.

Gerhard Postpischil
Bradford, VT

56 Replies
615 Views
Permalink to this page
Disable enhanced parsing

Thread Navigation

time2ipl 2008-06-30 01:17:43 UTC

Peter 2008-06-30 02:24:02 UTC

time2ipl 2008-06-30 04:38:15 UTC

Peter 2008-06-30 06:11:39 UTC

Peter 2008-06-30 06:18:15 UTC

Harold Grovesteen 2008-06-30 17:54:41 UTC

Dave Wade 2008-06-30 12:10:07 UTC

kerravon86 2008-06-30 12:58:39 UTC

time2ipl 2008-06-30 16:59:17 UTC

Peter 2008-06-30 20:14:16 UTC

Jim Morrison 2008-06-30 20:35:19 UTC

kerravon86 2008-06-30 22:24:35 UTC

Phil Dickinson 2008-06-30 22:44:52 UTC

Sterling Garwood 2008-07-01 02:51:03 UTC

Jim Morrison 2008-07-01 08:03:10 UTC

halfmeg 2008-07-01 17:58:06 UTC

Jim Morrison 2008-07-01 21:31:19 UTC

Jim Morrison 2008-07-01 21:36:55 UTC

David Wade 2008-07-01 20:41:25 UTC

kerravon86 2008-07-02 12:41:53 UTC

halfmeg 2008-07-01 03:06:14 UTC

time2ipl 2008-07-05 16:59:57 UTC

kerravon86 2008-07-06 01:40:45 UTC

Grzes Plucinski 2008-07-06 08:48:32 UTC

time2ipl 2008-07-09 04:49:28 UTC

kerravon86 2008-07-09 10:14:13 UTC

rfochtman 2008-07-09 15:10:22 UTC

Greg Price 2008-07-10 12:03:14 UTC

time2ipl 2008-07-09 15:51:54 UTC

scott 2008-07-09 17:21:21 UTC

time2ipl 2008-07-09 19:24:30 UTC

kerravon86 2008-07-09 22:39:20 UTC

time2ipl 2008-07-10 02:20:54 UTC

kerravon86 2008-07-10 15:23:22 UTC

time2ipl 2008-07-11 16:16:58 UTC

kerravon86 2008-07-11 19:36:02 UTC

time2ipl 2008-07-11 23:03:35 UTC

kerravon86 2008-07-11 23:25:02 UTC

time2ipl 2008-07-12 04:23:11 UTC

halfmeg 2008-07-12 05:14:02 UTC

kerravon86 2008-07-12 05:38:14 UTC

kerravon86 2008-07-12 05:26:47 UTC

Gerhard Postpischil 2008-07-14 03:29:36 UTC

kerravon86 2008-07-14 11:41:27 UTC

Gerhard Postpischil 2008-07-14 15:32:30 UTC

peter_flass 2008-07-15 11:13:07 UTC

Gerhard Postpischil 2008-07-15 18:53:45 UTC

antoniofilgueirajunior 2008-09-02 16:10:04 UTC

Thomas David Rivers 2008-06-30 13:25:22 UTC

rfochtman 2008-06-30 16:16:50 UTC

cedarlakebuzzards 2008-07-07 07:17:24 UTC

Dave Wade 2008-07-07 07:22:14 UTC

Davide Grandi 2008-07-07 12:42:52 UTC

cedarlakebuzzards 2008-07-08 10:56:17 UTC

Dave Wade 2008-07-08 12:56:44 UTC

Phil Dickinson 2008-07-08 21:15:24 UTC

Gerhard Postpischil 2008-07-14 03:17:48 UTC

about - legalese

Loading...