TCP/IP on 3.8j

[halfmeg]

I'm really hoping that works in a halfway clean manner.

Believe he is referring to TCP/IP utilizing dyn75 and m38tcp.tar.bz2
contents.

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

CTCAMAIN.VS1 program was uploaded to hercules-390 files section by
wably in April of 2006. Only mention that a search on the messages
turned up was:

http://tech.groups.yahoo.com/group/hercules-390/message/46630

I'm having problems getting MVS/380 installed;

You have come late to the party and perhaps don't know of the fork
taken by Paul with his modification to Hercules-390. It has it's
place but, is see by me to be a distraction from constructive and
productive development in other areas. ( Most recent example of this
is from yesterday on the VM forum where someone relented and just went
ahead and tested something for Paul. Then when the expected results
were not forthcoming, more tests, changes were requested. This takes
one away from an area where they might have expertise to accomidate a
seemingly unrelenting try this, try that, it's only 20 lines of code,
etc... ). Other examples are on this forum and previously in the VM
forum.

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

SOFTLIB.ORG is the right place. The procedures for applying them to
the Turnkey CD System #3 are in a post I made over in the turnkey forum.

http://tech.groups.yahoo.com/group/turnkey-mvs/post?act=reply&messageNum=3751

Copied below for those who might not be a member of that group. Some
of the links have changed as SOFTLIB moved since the initial work on
the shadow update.

Softlib is moving and classiccmp has graciously allowed us to be
hosted there. The softlib link will be redirected after I finish
uploading the rest of the old site to the new location.
Phil - original post replied to as I have forgotten everything we
did in the shadow update
There is a fixpack1.zip file as well which should be run after the
TK3SU1.zip is applied to correct a few minor/major glitches. It is
also found at the above link.

We have been working a little recently to bring you a fairly large
update to the MVS TK3 system. The list of things included are
www.bsp-gmbh.com/turnkey/tk4wish.html
with updates of RPF and IND$FILE to even more recent versions and a
bug fix for the XMIT/RECV package.
I believe that 2, 5*, 6, & 7 on the still to-do list are also done.
( * JES3 is a very recent addition and currently is on the same
sysres as JES2 ).
As with a lot of things, some small things slip through the cracks.
I forgot to include a README in the update zip file itself. One of
the testers reported a need to specify a REGION statement on jobs
submitted under JES3 as I didn't increase the default from 52K or
so.
www.box.net/public/at0xixe608#main < no longer valid <<<<----<<<<<
It is slightly less than 63 Mb.
It should be applied to a fresh or clean install of the TK3 base
system. You don't have to have all the packs installed. If you
selected to leave the CBT, SRC, SMP and starter system packs
uninstalled, this update should still work with your MVS
environment.
So the procedure would be.
1. Clean install of TK3.
2. Unzip of TK3SU1.zip into the directory where TK3 was installed
ie c:\mvs38j or similiar
At this point a new config file ( TK3SU.conf ) will be placed in
your config directory which will need to be used for hercules
startup. If you start Hercules with the line commands it would be
hercules -f conf\tk3su.conf
New DASD base files for the added packs like DLIxxx and JSxxxx will
be added to the DASD directory and the bulk of the data will be
added to the SHADOW directory as shadow disk files.
For routine operation of JES2, the startup is identical to 1st time
TK3 startup I believe.
3. Start hercules
4. Connect your 3270 client and telnet client as you would normally
5. IPL 148
6. to IEA101 message reply R 0,CLPA
7. JES2 will terminate due to unformatted spool and checkpoint
8. S JES2, reply 'r x,cold,format'
9. $S when it asks you to enter requests
10. The system should be up and running at this point with all the
new stuff ready to use.
Now for those who want to experiment a little. You can run the
updated system with a security package. You have a choice of 2
different ones, RAKF or PIES. This is currently only available with
the JES2 environment and has to be selected at IPL time. When the
IEA101 message appears, reply, 'r 0,sysp=PI' for PIES or
'r 0,sysp=RA' for RAKF.
For the even more adventurous, you can experiment with JES3. At IPL
time when presented with the IEA101 message, reply r 0,sysp=j3 and
you will soon see some different messages and required responses to
bring JES3 up and running.
IAT3011 SPECIFY JES3 START TYPE
*00 IAT3011 (L H HA W WA OR C)
give this a r 0,C
*01 IAT3033 CONFIRM JES3 COLDSTART REQUEST (U)
and a r 1,U
*02 IAT3012 SELECT JES3 INISH ORIGIN (N M= OR U=), AND OPTIONAL EXIT
PARM (,P=)
and a r 2,N
then this shows up
0142007 IAT3100 JES3 3.0.0 SYSTEM COLDSTART ON 6.337 AS SY1
enter *s jss
An important note here, we haven't configured any JES3 consoles in
the system ( remember very recent addition ) so the telnet console (
formerly 009 now moved to 01F ) is your main console for JES3 as
delivered currently.
You can start the card reader and output printer.
*x cr,in=00c,k
*x wtr,out=00e
8s 00e
* & 8 are interchangable in the JES3 command systax for 1st
character
You are now ready to run a job, but not to logon on TSO. Why you
may ask. Because of that other twist of fate. I didn't add all
the start up commands that the JES2 side already has in place. If
you want to run under JES3 and log on to TSO , just enter 's net' &
's tso'. Your 3270 client tso terminal should be ready for you to
logon. This should also help to remind you that the JES3 stuff is
a work in progress.
How do I shut this beast down. Ok, if you have started up TSO,
enter 'p tso' followed by a 'U' to the reply that appears. Then
enter 'z net,quick' to shutdown VTAM. Enter 'P CMD1' to stop CMD1
and finally you enter '8return' to shutdown JES3. You can now
'power off' Hercules.
If it all works, it's the effort of many people, if it's broken,
blame me.
Phil - a space blanket, that's what I need - they'll never find me
in space

Phil - too bad PSI got swallowed by the whale, but what does that say
for FSI and the whale's appetite

[kerravon86]

Post by halfmeg

I'm having problems getting MVS/380 installed;

You have come late to the party and perhaps don't know of the fork
taken by Paul with his modification to Hercules-390. It has it's
place but, is see by me to be a distraction from constructive and
productive development in other areas.

There's a lot of things you "see" that don't exist
in reality.

Post by halfmeg
( Most recent example of this
is from yesterday on the VM forum where someone relented and just went
ahead and tested something for Paul.

You mean after I relented and downloaded VM after I
was told something wasn't technically possible (again)?

Maybe you didn't see that and only saw what you wanted
to see?

Post by halfmeg
Then when the expected results
were not forthcoming,

Actually the results were exactly as I expected. The
interrupt took away the 24-bit too quickly and I was
already searching for a solution to that technical
problem.

Post by halfmeg
more tests, changes were requested.

Not until after I murdered 5 babies and stuffed
them in the boot of a stolen car mind.

Post by halfmeg
This takes
one away from an area where they might have expertise

Actually it was specifically utilizing their expertise
to come up with a technical solution to the problem
stopping GCC from self-compiling optimized under VM.
Just because you have apparently have no interest in
GCCCMS being able to self-compile under VM, I happen
to have an interest in that. As far as I am aware, I
didn't violate as many human rights trying to solve
that problem as you seem to think I did.

Also note that anyone who attempts to use GCC to
build another language from the collection is going
to need even more memory than that.

Post by halfmeg
to accomidate a
seemingly unrelenting try this, try that, it's only 20 lines of code,
etc... ).

Yes, development normally consists of multiple
iterations. I don't know why they designed the SDLC
that way. A more obvious way would just be to require
programmers to write bug-free code in the first
phase. We need a manager with great ideas like that
where I work.

Regardless, I provided the 5 lines of code to do the
test, as I said were required.

The 20 lines I will write after the 5 lines are
working as I wish them to work. Like I say, they
follow a whacky SDLC down here so I don't know
any better.

Also note that the technical solution appears to
be able to be generated fairly quickly, especially
given that VM hasn't been able to do what MVS was
able to do for 8 months.

Post by halfmeg
Other examples are on this forum and previously in the VM
forum.

Other examples of you accusing innocent people of
various outrages while they are trying to write
software? Yep. You'll definitely find them.

[note to others - none of what I said here takes away
anything from the enormous contribution Phil made to
get GCCMVS working. I'm not sure why installing
TK3 and GCCMVS on my own machine (and fixing the
encountered problems) was such a controversial thing
to do that Phil is still bitter about it 1 year on,
but there you go].

BFN. Paul.

[time2ipl]

Post by halfmeg
Believe he is referring to TCP/IP utilizing dyn75 and m38tcp.tar.bz2
contents.

Yup. Actually, given that in the Files section of this very forum
there's two sets of code for the thing (dyn75): m38tcp.tar.bz2 and a
subdirectory called "TCP-IP Dynamic Module", both of which contain
different files, and neither of which contain much anything in the way
of documentation, I'm not really sure what, exactly, I'm talking about...

The other part of the puzzle is this: the makefile in m38tcp.tar.bz2
flat out doesn't work. That's fair; things change, etc.; it seems to
have been written for an older version of Hercules. However, with no
documentation at all, I'm starting to get "that sinking feeling". For
example, I don't know what the soname for the thing is supposed to be,
what the name of the actual library is supposed to be, etc. The .conf
files from TK3SU1 all seem to have "ldmod dyninst dyn75" in them...

That's great, but how the heck are they building the module: with
which files (one of the two sets mentioned above, or is there a
third), and how (what soname is being used, etc.); at this point, I
don't even have a working dyn75.so (I'm assuming that's what it's
called) to run "readelf" against and try to match mine up to it.

Initially, I thought the trick would be to generate a "dyn75.so"
that's equivalent to the other .so's in /usr/lib{,64}/hercules, but so
far, that hasn't worked out too well; I did successfully build a
module, but the library/file name is == its soname, and there were
some pretty scary pointer conversion warnings ("cast from integer to
pointer of a different size"): some of the code in m38tcp.tar.bz2 is
written w the assumption that sizeof(int) == sizeof(char *). Which
isn't the case on my amd64 systems (not in 64-bit mode, anyway).

Post by halfmeg

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

CTCAMAIN.VS1 program was uploaded to hercules-390 files section by
wably in April of 2006. Only mention that a search on the messages
http://tech.groups.yahoo.com/group/hercules-390/message/46630

Ah. Thanks... The bad news, is that after reading the follow-up
messages to that post, it seems that that code was written for OS/360
and won't work "as is" under MVS.

With my (very) limited knowledge of 370 assembler, I would have been
lucky to have figured out how <it> worked; I'm not going to be
re-writing it for MVS on my own any time soon... I don't have the
foggiest clue what some of the things that the person who wrote the
"it won't work under MVS" post are, let alone how to fix them.

I guess I'm pretty much back where I started. Does anyone have a
sample, that works, which would allow me to transfer data real-time
between an MVS machine and another machine, that's not dependent upon
Hercules (i.e., that I could conceivably take and run on real hardware?)

My idea had been to use the mainframe as a sort of web server /
document server; I still think it'll work, and I'm told by IBM that we
could do it with SNA && Webshpere MQ, but that seems to be complete
overkill.

Thanks for explaining what that code is, though. At least now I won't
be tilting at windmills trying to get <it> to work.

Hopefully somebody out there has a CTC sample that works, for MVS...

- Larry

[halfmeg]

Post by time2ipl
Yup. Actually, given that in the Files section of this very forum
there's two sets of code for the thing (dyn75): m38tcp.tar.bz2 and a
subdirectory called "TCP-IP Dynamic Module", both of which contain
different files, and neither of which contain much anything in the
way of documentation, I'm not really sure what, exactly, I'm talking
about...

I had hoped you were wanting something like:

"MVS Batch Job Submission through FTP

Submit JCL on Remote Mainframe machine from your Windows Machine or
Unix Machine.

Steps

1. Log on to Mainframe Server
2. Use command quote site filetype=jes
3. Use Put command to execute the local JCL on Mainframe.
4. Use ls command to see the status of your Job.
5. Use Get command to retrieve the outpu log of the Job.

Example

ftp a.b.c
lcd a/b/c
quote site filetype=jes
put sample.jcl
ls
get job12345
quit"

Actual example:

"Command:
User: site file=jes
System: >>>SITE file=jes
Server: 200 Site command was accepted

Command:
User: put 'user121.jcl.cntl(mvsjob)'
System: >>>SITE FIXrecfm 80 LRECL=80 RECFM=FB BLKSIZE=27920
Server: 200 Site command was accepted

Post by time2ipl

PORT 9,67,112,25,4,37

200 Port request OK.

Post by time2ipl

STOR 'user121.jcl.cntl(mvsjob)'

125 Sending Job to JES Internal Reader FIXrecfm 80
250-It is known to JES as JOB02189.
250 Transfer completed successfully."

Along with normal file transfer functions.

Post by time2ipl
The other part of the puzzle is this: the makefile in m38tcp.tar.bz2
flat out doesn't work. That's fair; things change, etc.; it seems
to have been written for an older version of Hercules.

The original TCP work was probably about version 2.16 of Hercules.
Since then the instruction format within Hercules changed by a bit or
byte here or there and dyn75.c would no longer work ( compile error )
with the more recent versions.

A quick and dirty make using the contents of m38tcp.tar.bz2 on a
32-bit Linux environment with GCC 3.3.4 as the compiler gives the
following results.

"make
cc -O3 -march=i686 -fomit-frame-pointer -I. -I../hercules -W -Wall
-DHAVE_CONFIG_H -o m38tcp.o -c m38tcp.c
cc -O3 -march=i686 -fomit-frame-pointer -I. -I../hercules -W -Wall
-DHAVE_CONFIG_H -o tcpip.o -c tcpip.c
cc -O3 -march=i686 -fomit-frame-pointer -I. -I../hercules -W -Wall
-DHAVE_CONFIG_H -o tcpunix.o -c tcpunix.c
tcpunix.c: In function `EZASOKET':
tcpunix.c:633: warning: dereferencing type-punned pointer will break
strict-aliasing rules
tcpunix.c:797: warning: dereferencing type-punned pointer will break
strict-aliasing rules
cc -o dyn75 m38tcp.o tcpip.o tcpunix.o -shared

A ls -l shows:

-rwxr-xr-x 1 root root 60317 2008-07-13 00:02 dyn75*

as the produced module.

When I attempted to load it with Hercules 3.05 ( might be a snapshot )
I recieved:

ldmod /root/m38tcp/dyn75

HHCHD100I Loading /root/m38tcp/dyn75 ...

HHCHD011I Dependency check failed for REGS, size(58164)
expected(56120)
HHCHD011I Dependency check failed for SYSBLK, size(59824)
expected(57784)
HHCHD014E Dependency check failed for module dyn75

Which is the type of stuff I have seen before with this thing being
compiled without the 'matching' specific Hercules release.

Then again it could be that a quick and dirty test on a test
environment is causing this.

Post by time2ipl
However, with no documentation at all, I'm starting to get "that
sinking feeling". For example, I don't know what the soname for the
thing is supposed to be, what the name of the actual library is
supposed to be, etc. The .conf files from TK3SU1 all seem to have
"ldmod dyninst dyn75" in them...

The linux example above doesn't have a extension to my knowledge. The
windows MSVC and CYGWIN versions are dyn75.dll .

Post by time2ipl
That's great, but how the heck are they building the module: with
which files (one of the two sets mentioned above, or is there a
third), and how (what soname is being used, etc.); at this point, I
don't even have a working dyn75.so (I'm assuming that's what it's
called) to run "readelf" against and try to match mine up to it.

You have lost me on soname and readelf ( Newbie here ).

There are at least 4 'distributions':

Jason's original ( which I have ).
m38tcp.tar.bz2 in H390-MVS files section
TCP-IP Dynamic Module folder in H390-MVS files section
recent upload of dyn75 in Hercules-390 main files section

5 if you count the files already included in the TK3 Shadow Update (
dyn75 code not included as that is Hercules related ).

Jason's original has some documentation but there is no longer a web
site which posts that. Someone else mentioned his work was $-ware and
looking at one of the files in his distro that is mentioned. I have
no idea if that is still the case or not as his copyrighted code seems
to be in all the other items above with no mention of license conditions.

Post by time2ipl
<snip>
Which isn't the case on my amd64 systems (not in 64-bit mode,
anyway).

While I could set up a test bed for 64-bit environment, each time I
have attempted a 64-bit Linux install there seemed to be a lot of
bugginess involved with things ( been over a year ago now - maybe it's
improved ).

I also build Hercules from source on the Linux side instead of messing
with the RPMs.

Post by time2ipl

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

I may have posted earlier about using a 2703. There are two RJE
emulators which work with the TK3 Shadow Update. It might be possible
to utilize one of them to do what you want.

Post by time2ipl
I guess I'm pretty much back where I started. Does anyone have a
sample, that works, which would allow me to transfer data real-time
between an MVS machine and another machine, that's not dependent
upon Hercules (i.e., that I could conceivably take and run on real
hardware?)

IIRC, there is a program in the MVS 3.8j SAMPLIB which connects to
another system ( RMT360 or something like that ). I don't know what
type of connection it is looking for or what the capabilities are.

Post by time2ipl
My idea had been to use the mainframe as a sort of web server /
document server; I still think it'll work, and I'm told by IBM that
we could do it with SNA && Webshpere MQ, but that seems to be
complete overkill.

I had wanted to get TCP/IP working on MVS 3.8j for the Shadow Update.
At this point I will probably rebuild Jason's original package to
verify everything worked ( he stated it did in his documentation ).
Then move to current release of Hercules to see if it still works.
Then see if GCCMVS generated programs permit successfull operation. A
discussion in another forum posed the idea that Jason's EZASOCKET and
mainframe side C programs were written for use with the JCC compiler
library functionality in mind. This might be another reason for
partial function when compiled with GCCMVS.

Post by time2ipl
Thanks for explaining what that code is, though. At least now I
won't be tilting at windmills trying to get <it> to work.
Hopefully somebody out there has a CTC sample that works, for MVS...

Phil - the JES3 source has examples of CTC communication which work

[halfmeg]

Post by halfmeg
Then again it could be that a quick and dirty test on a test
environment is causing this.

1. Started with a fresh compile of Hercules 3.05
2. Compiled dyn75 from dyn75.zip file located in Hercules-390 files
section
3. Laid down fresh TK3
4. Applied Shadow Update for TCP stuff ( MVS.TCPIP.* datasets )
5. IPLed
6. Started FTPD.FTPD on MVS Console
7. Then from linux aterm window - ftp 127.0.0.1 21

and we get:

Connected to 127.0.0.1.
220 *** MVS38j FTP Daemon ***
Name (127.0.0.1:root):
331 Okay, waiting for password.
Password:
230 You are now logged in.
Remote system type is MVS.
ftp> get mvs.stage1.output
local: mvs.stage1.output remote: mvs.stage1.output
200 PORT command successful
125 Data connection open, starting transfer
WARNING! 14052 bare linefeeds received in ASCII mode
File may not have transferred correctly.
226 Transfer complete!
541545 bytes received in 0.194 secs (2.7e+03 Kbytes/sec)
ftp> quit
221 Bye!

A quick glance at the file after download looks like the stage1 output
which is punched out normally. Another test with compare to actual
punched deck would be needed to verify.

Shadow Update is not required for TCP/IP and the above seems to
only work for offload of PS dataset. All other quick tests get ACCESS
DENIED message.

Phil - still in quick and dirty test mode to refresh my memory

[kerravon86]

Post by halfmeg
1. Started with a fresh compile of Hercules 3.05
2. Compiled dyn75 from dyn75.zip file located in Hercules-390 files
section
3. Laid down fresh TK3
4. Applied Shadow Update for TCP stuff ( MVS.TCPIP.* datasets )
5. IPLed
6. Started FTPD.FTPD on MVS Console
7. Then from linux aterm window - ftp 127.0.0.1 21
541545 bytes received in 0.194 secs (2.7e+03 Kbytes/sec)

Wow! So does this mean FTP will likely work for
Windows users too?

Post by halfmeg
Shadow Update is not required for TCP/IP

What does this mean? FTP comes standard with TK3?

BFN. Paul.

[halfmeg]

Post by kerravon86

Post by halfmeg
2. Compiled dyn75 from dyn75.zip file located in Hercules-390
files section

Wow! So does this mean FTP will likely work for
Windows users too?

Testing was done with a Windows version back when I was working on the
shadow update. It was previous to 3.05 release however and provided
to assist in testing.

The reason I chose the dyn75.zip file above was that it has the MSVC
makefile included in the package. If it turns out that that version
of dyn75 doesn't work, I'll revert back to the original version of
both dyn75 and Hercules it was written for.

Post by kerravon86

Post by halfmeg
Shadow Update is not required for TCP/IP

What does this mean? FTP comes standard with TK3?

The FTP source and linked programs are already incorporated into TK3
Shadow Update only, not plain TK3.

When or if this stuff works, I will package so that it can be utilized
by plain TK3 as well as the Shadow Update.

Phil - since it didn't work right, it wasn't 'advertised'

[halfmeg]

Post by time2ipl
<snip>
Phil - since it didn't work right, it wasn't 'advertised'

After more than some 'tinkering' with this stuff, I stumble across a
key item which allows it to work.

First, a little history.

Jason Winter adapted the Dumb As Fudge perl FTP daemon and wrote some
additional C source to permit a FTP daemon to run on MVS 3.8j. He
compiled his code with JCC ( a C Compiler no longer available ). It
probably all worked. There is even a MVS email job for sending email
from the mainframe.

Volker packaged some libraries for loading to the Turnkey via an AWS
tape to implement TCP/IP. He also uploaded to the TK4 Beta group
files section a Windows binary which has the required dyn75.dll included.

During TK3 Shadow Update testing, Volker and I both utilized ( AFAIK )
a FTP client package called SEAGULL FTP. Neither of us progressed
much beyond transfering a flat file out of MVS. Most everything else
gave 'ACCESS DENIED' or in my case hung at the end of the upload to
the mainframe.

Back to current testing.

During startup of the FTPD task, it creates a list of files which are
located on the packs listed in SYS1.PARMLIB(VATLST00) ( I think ). If
you attempt to upload a file to a dataset not in the list you get
'ACCESS DENIED'. If you attempt to upload a file to a dataset you
have browsed via TSO, you get something like 'Failure 13' until you
logoff TSO. If you upload a file bigger than will fit in the
allocated dataset you will get an Abend SD37 in FTPD, a possibly hung
FTP session where you initiated it until you submitt the 'RESET' job
on the mainframe side, then start FTPD again ( I think ).

As long as the file was catalogued when FTPD was started, it appears
transfers in and out are working using LINUX and WIN2k commandline FTP
utility as well as the SEAGULL FTP client.

I think there is code for handling PDS members also but I haven't done
any testing in that area yet.

There is a method to stop the FTPD job cleanly, which needs to happen,
or subsequent attempts to start it may fail fairly quickly. Another
job 'RESET' which wasn't placed in the PROCLIB needs to run. It can
be submitted at a TSO prompt and FTPD will end ( this frees all the
sockets that have been 'grabbed' by FTPD ) ( I think ).

Notice a lot of 'I think' in the stuff above. Although I have gotten
through some of the gottchas, there are still more.

Phil - taking a break for a little while