Building MVS/380


As things currently stand, MVS/380 is shipped as an
infrastructure. There are lots of different 3rd party
products you may wish to install, and you need to find
someone who has followed the below procedure to create
a set of shadow files that satisfy your requirements.

Note that the requirements for the builder are different
from the requirements for the user. E.g. Cygwin is not
required as a user for most MVS/380 functionality.


You must have PDPCLIB, GCC, BISON, SED and other tools 
extracted. You also need Cygwin installed (or at
least the various utilities). You must have a "make"
that accepts spaces, e.g. the one provided with
Borland C++ 5.5.1 (free).

The MVS/380 code itself must be extracted with something like:
cvs -d :ext:kerravon86@mvs380.cvs.sf.net:/cvsroot/mvs380 get mvs380

Also, if you are importing more source code, you need to
do something along these lines:

cvs -d :ext:kerravon86@mvs380.cvs.sf.net:/cvsroot/mvs380 import -k o -I ! -m "initial import" mvs380 turnkey tk3-linenum

then strip the line numbers using:

clnblank '*.mac' '../stripped/*.mac' 72 

e.g. if converting macros.

clnblank is a tool from OZPD which should be compiled with -DUNIX
under Cygwin.

These procedures assume you have checked out
mvs380 (from sourcforge CVS)
gccmvs (applied patch etc)
various other products also sitting on hard disk

an environment variable called MVSTOOLS is set and points
to where all the products can be found.

MVS380 is also set to point to where mvs380 is checked out

And you have a freshly installed "tk3" zipped up.


The following problems exist:

In order to build gcc properly, you need bison
In order to build bison, you need gcc
In order to build gcc, you need updated macros
In order to get the updated macros, you need mvsunzip, which needs gcc

So:

putmacs:
1. Build the 370-utilities including mvsunzip using the cross-compiler
2. Get the modified macros up

allgcc:
3. build gcc compiler and pdpclib utilities normally

allbis, allsed:
4. build bison and sed normally


withbis:
5. put source up except for to-be-generated stuff
6. after stage1, copy stage1 executable to gcc.linklib
7. generate extra source using gencomp
8. save copy of source
9. delete gcc.linklib and reallocate
10. do 2-stage compile to get matching assembler


allbis, allsed:
11. rebuild bison and sed

checkgen:
12. regenerate extra source
13. compare source to saved source to ensure identical, cleanup



Now everything is purely mainframe-built


Because all of this created massive amounts of datasets that were
subsequently deleted, which conflicts with the ability to do
compression, unload all of them, get clean disks, then reload.

Then go and compile all the other products.


So, that's the why.  Here's the how.

1. Extract all source for mvs380 and products.
2. Run "build380".
3. Run "check" to see if any obvious errors.
4. Rename old mvs380 directory
5. Check out fresh mvs380 directory with "export" of tag
6. Move the "shadow4" directory into an empty directory
and then rename it to just "shadow".
7. Copy any extra new disks you created, e.g.
md dasd
copy \mvs380\dasd\dli* dasd
copy \mvs380\dasd\js* dasd
8. Zip up the shadow and dasd directories from the empty directory so
that those words go into the zip archive, which is
required for later extraction. e.g.
zip -9rX \download\shadow *


Or, take a look at "thelot.bat" which will do everything
required.

In development, you can instead modify runmvs.bat so that
it redirects the output, then go:
build380 2>&1 | tee build380.log
