Welcome to the OS390::Stdio module.

In order to build this extension to perl you must get
the gzipped tape archive over to OS/390 (ftp or nfs in binary mode).
In summary the steps you need to execute are:

    gunzip OS390-Stdio-0.004.tar.gz
    pax -f -t < OS390-Stdio-0.004.tar
    cd OS390-Stdio-0.004
    perl Makefile.PL
    make
    make test
    make install

If your perl is built to only allow static linking (as is common on OS/390)
then be sure to also run:

    make inst_perl

In detail the steps are:

Unpack the ASCII source code archive (the gunzip can be done on a non 
OE machine if necessary):

    gunzip OS390-Stdio-0.004.tar.gz
    pax -f -t < OS390-Stdio-0.004.tar

then configure and build (see `perldoc ExtUtils::MakeMaker` for more
information on building staticially linked perl extensions and other 
options to pass to perl on the `perl Makefile.PL` step, as well as
the section "Build tips" below for more info):

    cd OS390-Stdio-0.004
    perl Makefile.PL  [-DNO_WARN_IF_NOT_PDS]
    make

(optional) now make a static perl binary:

    make perl

now run the regression test:

    make test

(see also the section "Regression testing tips" below for more info).

If things look "OK" then install (this may require UID=0 or simply 
write privileges to the appropriate directories):

    make install

(optional) install the statically linked rebuild perl binary:

    make inst_perl


"Documentation"
---------------
Documentation is within Stdio.pm and should be available with:

    perldoc OS390::Stdio

There are also examples of working data set handling code in test.pl,
as well as in pds_test.  This latter program can be run after
`make test` and it will prompt you for some valid data set names. 

You can find GNU make as well as gzip/gunzip at:

    http://www.mks.com/


"Build tips"
------------

I've had no luck with versions of perl prior to 5.005_02.  Hence I
would recommend that you try that or an even later version of perl.
I've also noted that the build works just fine on these:

    $ uname -v -r
    05.00 02
    $ uname -v -r
    06.00 02
    $ uname -v -r
    07.00 02
    $ uname -v -r
    10.00 02

But has trouble with __dyninit_t and fldata_t structs on:

    $ uname -v -r
    03.00 01

I'd be happy to resolve those build problems with someone - send
me a unified or context diff of the changes you had to make.  Thanks.

Also, I might like to rename this module to S390::Stdio if possible.  
That is, I would like to provide stdio extensions to folks on VSE/ESA, 
VM/CMS, etc.  Of course I would be willing to rename mvsopen() and 
mvswrite() if such generalization proves feasible (I'd consider 
s390open() and s390write() if they didn't have a soon-to-expire 
timestamp in them).  Any help with such a project would be greatly 
appreciated since I do not have routine access to VSE or VM.
Thank you.

"Regression testing tips"
-------------------------

In order to see more of what the regression tests are doing look for 
the %ENV varaibles to set, set them, then re-run the `make test` suite.
e.g.:

   $ grep ENV test.pl
   my $DIAG = $ENV{'OS390_STDIO_DIAG'};
   my $GORY = $ENV{'OS390_STDIO_GORY'};
   $ export OS390_STDIO_DIAG='1'
   $ make test

After the `make perl` or `make test` step it should be posible to run 
the pds_test test via:

   ./pds_test

Then answer the questions that arise.  The pds_test script will ask for 
a PDS name and a non-PDS data set name, and will attempt to read 
the DCB and MEMBER list from each as a means of testing pds_mem().  
See also the comments at the head of pds_test for other tips on 
running it.

##################################################################

Special notes for release 0.004:
--------------------------------
The pds_mem() routine now does a better job of EXTENDing the 
perl XS ST-ack and ought to work with PDS'es that have more than
100 members.  It does not list ALIAS members as was noted
in testing (and documented in Stdio.pm).  A more extensive
test of pds_mem() has yet to be written.  All 70 tests ought to
pass for you though.

None of the catalog/VTOC dslist functions (vol_ser dsname_level) work.
I am beginning to suspect that I may need to use the ISPF callable 
interface or even (eeks!) ASM (shudder).  Help would be appreciated.

None of the vsam routines [locate() update() delrec()] have been 
tested at all.  Any volunteers to write tests?

##################################################################

See the Changes file for older information.

Peter Prymmer