Post by Bernd Oppolzer ***@yahoo.com [hercules-390]Thank you very much, it works !
say "usage: copymvs <pcfile> <mvsfile>"
That looks like the start of something
very beautiful.
You have encapsulated the copy process
with a script, such that the internals can
change without the user being affected.
Note that although I have my own scripts,
they all involve MVS being shut down,
and I'm the only person on the planet
that operates MVS with a fresh IPL
every time. So you have an opportunity
to corner the market here, if you can
get it all working.
One thing that you don't have in your
script is a "binary" option. To implement
binary transfer (e.g. a zip file) using
your existing JCL, you can encapsulate
your binary input file with mvsendec,
which you should already have, but
if not, it is here:
http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/pdpclib/mvsendec.c?view=markup
Using the encb and decb options.
Sending a huge file up via the card
reader has an issue that you might
fill up the spool. You might be able
to avoid that problem by using a
second card reader for your data
file, I don't know. Personally I think
the correct solution to this problem
is to use tape instead of cards. On
tape you can have a proper
RECFM=U file.
You define a tape with a RECFM=U
binary file on it like this:
C:\mvs380\tapes>type pctomf_bin.tdf
@TDF
hercauto.dat FIXED RECSIZE 6144
TM
TM
EOT
C:\mvs380\tapes>
I think the above is quite confusing. It
says "FIXED" but actually it supports
RECFM=U with a short last block.
Or RECFM=FB with a short last block
too.
But in order to use tapes, you need
some way of doing a devinit on the
tape drive. In my case the startup
scripts automatically do the required
devinits before starting the card
reader. I don't actually know how to
do it automatically on a running
system. I vaguely recall that there
is an MVS utility that allows you to
execute Hercules commands.
Note that in my case I don't care
about time taken for repeated IPLs
since I can IPL and run an
IEFBR14 in about 4 seconds.
Even if you feel the need to keep
your system up permanently, you
can still encapsulate all of your
work into a batch file. E.g. when
I am building any utility, e.g.
brexx, sed, minizip etc etc, all I
do is type in "allmvs" at the
Windows prompt. Here's an
example:
C:\devel\brexx\mvs>type allmvs.bat
del alljcl.jcl
del output.txt
call zipmvs
call subjobs
C:\devel\brexx\mvs>
Depending on what you are doing, you
too could zip up all your Pascal
development and send it to the
mainframe and sit back and relax
waiting for a result.
Note that building BREXX or whatever
takes about 5 minutes, as I am too
lazy to even switch off optimization
during development, or tailor the
JCL to only rebuild the module of
interest. Some people do nothing and
just listen to music to relax. I sometimes
listen to music and relax while a build
is going on. Or eat dinner if I am
rebuilding GCC which takes about
an hour rather than 5 minutes.
I think you should aim to replace my
runmvs command:
C:\>runmvs
Usage runmvs jcl.file print.file [aux_input.file|none] [aux_output.file|none] [ascii|binary|rdwund|rdwvar|vart] [ascii|binary] [awstap.file|none]
e.g. runmvs compile.jcl output.txt world.c world.s ascii ascii
or runmvs buildgcc.jcl output.txt source.zip xmit.dat
default is for files (if provided) to be binary
C:\>
with an identical command that instead
communicates with a running system.
Preferably with comments in English
so that others can maintain it too!
Like I said - there's a market out there
to corner. :-)
Technically even I may stop continually
re-ipling my system if there was a
replacement runmvs with no downside.
Although I really do like the consistency
of a fresh IPL for every run, so maybe
not. :-) But like I said - most people will
be using TSO and not want to exit their
TSO session. But if they're doing that,
then there's no point in runmvs anyway,
as their data is on the mainframe, not
the PC. So who knows. I guess it is
you personally who needs to define
what you are trying to do and thus
what scripts would be useful.
BFN. Paul.