NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/bit/listserv/ibmmain/2876

Text File | 1992-12-22 | 27.0 KB | 516 lines

Comments: Gated by [e-mail]
Path: sparky!uunet!paladin.american.edu!auvm!UNB.CA!JAF
Message-ID: <[e-mail]>
Newsgroups: bit.listserv.ibm-main
Date:         Mon, 21 Dec 1992 20:44:10 AST
Sender:       IBM Mainframe Discussion list <[e-mail]>
From:         "Tony Fitzgerald [phone]" <[e-mail]>
Subject:      Re: VTAM-->JES2 SYSOUT
In-Reply-To:  Message of Mon,
              14 Dec 1992 12:18:29 -0700 from <[e-mail]
Lines: 503

On  Mon, 14 Dec 1992 12:18:29 -0700  Marvin Dodd <[e-mail].
COLOSTATE.EDU> writes:

> I am exploring ways to distribute reports to networked printers on a
> campus backbone using primarily TCPIP. The mechanism that we are going
> to use takes SYSOUT destined for an NJE site/printer and converts that
> to a TCP/IP lpr session with a network host. Clear? :-)
>
> My first stab at this requires that output to a VTAM printer LU be
> redirected to SYSOUT where I can examine it and redirect it to the
> correct NJE printer. Is there any VTAM application out there that
> looks like a printer to VTAM but redirects the report to SYSOUT?

This sounds a bit like the way that the old JES328X program from
IBM worked.  I don't know why you're trying this route.

We have an implementation of LPR/LPD for MVS which looks to JES as
an SNA NJE session.  It has a number of advantages over the IBM
implementation of LPR/LPD.  I'll include a standard note after my
signature if you're interested.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-  J. Anthony Fitzgerald                  Phone:     [phone]
   Computing Services                     NetNorth:  [e-mail]
   The University of New Brunswick              or   JAF@UNB
   PO Box 4400
   Fredericton, N.B.  Canada
   E3B 5A3

=======================  ENCLOSURE  ===================================

The following is a note which I have prepared about the current status
of the MVS implementation of BITNET II and LPR/LPD which I developed at
the University of New Brunswick.  I hope it will answer most questions.

At present we do not use the BITNET II protocol functions of the program
and the reasons are given below if you care to read.  We do, however,
make extensive use of the LPR/LPD functions of the program.

The programs are available by anonymous ftp from unbmvs1.csd.unb.ca
(131.202.1.2).  Since this is an MVS ftp site, you must remember to
"cd pub" before you try to issue dir or get commands.  The file
PUB.$README has useful hints on transferring files from the MVS site
and I would recommend that this file be fetched and read first.  The
file PUB.NJEIP.$README is also very useful and I will include part of
that file below.  That file will refer you to a discussion list for the
program and an alternate site and mechanism for getting the program.

The programs are also available from jupiter.sun.csd.unb.ca where they
are stored as UNIX compressed files.  Compression reduces the size of
the files by two thirds and means the files can be transferred in a
significantly reduced amount of time.  You must uncompress the files
before you can use them and this must typically be done on a UNIX
system.  So to use this source you would ftp the files to a UNIX system
using binary mode.  Uncompress the files on UNIX then ftp in binary mode
to files on MVS which are RECFM=FB,LRECL=80 then you can use the TSO/E
receive command to re-build the PDS containing the sources.

>======================  PUB.NJEIP.$README
The index level PUB.NJEIP contains the following files:

  The file $README (this document) is plain text.  The other files are IEBCOPY
or TSO/E TRANSMIT unloaded PDSes and must be reloaded by IEBCOPY or TSO/E
RECEIVE before they can be used.  The large PDS has been split into seven kits
so as to reduce the length of time it takes to ftp any one file and decrease the
probability that ftp will fail.  You should retrieve all the kits in either the
IEBCOPY or TRANSMIT set then restore the kits to a single data set.  The
TRANSMIT files are RECFM=FB, LRECL=80 and should be easier to ftp then the
IEBCOPY files which are RECFM=V.

$README   This document.
SCRIPT    Some documentation in DCF script format.
SRCLIB    Source and sample job streams.
          Note:  #C@NJEIP is the jobstream used to create these files.
                 #I@NJEIP is a model jobstream to install the program.

  Note that the programs in this system are not complete.  You must also
retrieve the files under the PUB.UTILITY index level.  The source program
invokes macros found in PUB.UTILITY.MACLIB and the load module requires support
routines found in $$N@UTIL which is linked from modules in PUB.UTILITY.SRCLIB.

--------------------  Program status  ----------------------------------

  The LPD/LPR code has been in use at UNB since September 1990 and is
reasonably solid.  The BITNET II protocol is not in production at UNB,
however, a version is available which has been fixed by Karl Kelley of
Iowa State University and is in production there.

Known problems with LPR/LPD code:

1.  Files received by the MVS LPD server must be formatted text with
  line feeds, form feeds, etc. where appropriate.   Files may be sent
  and received transparently, however, this program will not act as a
  filter per se.  Transparent files sent to JES2 for processing which
  are not already in EBCDIC may not process properly.  At UNB we
  provide support for an HP LaserJet attached via 7171 using a locally
  written FSS which provides some support for ASCII data files.

2.  Communication of JES2 type data (Forms, UCS, etc.) from UNIX is
  via the -C lpr option.  The RFC for LPR/LPD states that the text
  transmitted by the -C option is limited to 31 characters.  On SunOS
  I have observed no such limitation and the -C option is quite a
  servicable vehicle in our environment for transmitting JES2 type
  information to the server.  This may not be the case with other
  versions of UNIX.  The LPR client function will also place JES2 type
  data in the generated C record.  The presence of this data may cause
  problems with some versions of LPD.  We find no problem with SunOS
  and have a filter for a PostScript printer which uses data from this
  record in generating a separator page.

--------------------  Alternate program source  ------------------------

  The source for this program is also available from USC using a more
LISTSERV like mechanism.  If you have problems with ftp from UNB you
might try to retrieve it from the alternate site.  Use mail to send
commands to either SERVICE@USCMVSA or [e-mail].  Place
service commands in the message body as the subject line is ignored.
Any number of commands may be sent in one mail item.  Before requesting
any objects new users of SERVICE should send a HELP command and read the
response very carefully.  Take particular note of the comments about
non-NJE return addresses.

The NJEIP program and the UTILITY program which it requires are in the
MVSUTIL index, so the commands to get it are:

   GET MVSUTIL/UNB.NJEIP
   GET MVSUTIL/UNB.UTILITY

When the availability of new source is made in MVSLPD-L the announcement
will indicate whether updates have been made to UTILITY modules as well
as or instead of NJEIP modules and it should be necessary to retrieve
only the affected program(s).

--------------------  Problem/Request discussions ----------------------

  A discussion list has been set up for this program and is hosted at
USC.  You may subscribe by sending to LISTSERV@USCVM or @vm.usc.edu
the command:

   signup  mvslpd-l  your name

Comments may also be sent directly to the author:

   J. Anthony Fitzgerald                   Email:   <[e-mail]>
   Computing Services                      NetData: T4710@UNBMVS1
   PO Box 4400                             Phone:   [phone]
   Fredericton, N.B.,  CANADA              FAX:     [phone]
   E3B  5A3

-----------  current versions of members deleted from this file  -----

>======================  Original note sent to ibmtcp-l  Spring 1990
/su MVS implementation of LPR/LPD and BITNET II protocol

  On occasion, there will be a plaintive cries for an MVS implementation
of LPR/LPD or the BITNET II protocol.  I made such earlier this year.
For those who are still interested in an MVS LPR/LPD or NJE/IP that does
not require VM, this note may be of interest.

  I have included a note that I made up earlier this year when I
received a query about my work in progress.  The note has been updated
on several occasions, so it tends to be a bit repetitious and disjoint.

  I am sending it now because in the past couple of days, I have been
successful in establishing TCP/IP links between JES2 and RSCS and in
having files exchanged over the link.  A lot of testing remains,
however, the configuration with which I have to work will not stress the
program and I will probably not find many of the bugs that are almost
certainly in the code.

  I guess what I'm looking for is comments from more knowledgable people
about things I may have overlooked and an offer from one or two sites
that could give the program a proper stress to help test the code.  I am
still testing here, and may find more problems that will require fixing
before shipping even test versions.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-  J. Anthony Fitzgerald                   Phone:     [phone]
   Computing Services                      NetNorth:  [e-mail]
   The University of New Brunswick               or   JAF@UNB
   PO Box 4400
   Fredericton,  N.B.  Canada
   E3B  5A3

<<<<<<<<<<<<<<<<<<<< enclosure follows >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
HISTORY:

  At a planning session in Winnipeg in November 1989 some NetNorth
installation representatives met to discus the problems and strategy of
and for converting from BSC/NJE based TP lines to a TCP/IP based network
which would be initially funded by the National Research Council.
Initially, it was stated that we would use VMNET or equivalent to
maintain NJE connectivity over the TCP/IP backbone to retain current
function (LISTSERV, Sender Initiated File Transfer, Interactive
Messaging, etc.)

  To meet this objective, we at the University of New Brunswick decided
that we needed an MVS/JES2 version of VMNET as our 9370 was severely
overloaded and cound not handle the additional load that all NJE traffic
for New Brunswick and Prince Edward Island would entail.  Requests to
various lists basically found that nobody was working on an MVS version
of VMNET although several sites were interested.  Since our need was
urgent, we made the decision to study implementation and proceed if we
determined it to be within our capability (one programmer, limited
time).  We ordered VMNET from Princeton just before Christmas 1989 so as
to get the complete protocol specifications and a working copy of the
code that we could use for testing and study.

  In the meantime, just after NewYears 1990, our director saw some
discussion of print servers and was of the opinion that print services
is an area where our central facility could be of benefit to the
University community as a whole.  While the particular protocol that the
directory had seen was a VM implementation and in use at only one
institution our follow up found that LPD/LPR was a more common if less
powerful protocol that is far more widely available.  Moreover several
sites around the campus expressed interest for the central facility to
provide LPD server functions for their machines.

  Once more, requests to various lists found that nobody was working on
an MVS implementation of LPR/LPD although several sites were interested.
The Columbia LPR/LPD implementation was mentioned, however, when we
obtained a copy we found that it was too highly dependent on VM/CMS
services to be of much use, moreover, the implementation had several
shortcomings.  We began our own implementation of LPD/LPR for MVS,
however, keeping in mind our need for NJE/IP, I designed the code to
allow for later inclusion of other protocols.

  I have suspended development on the LPD/LPR aspect of the program as I
am also trying to develop a more general NJE/IP interface that could
talk to the Princeton VMNET program.  We consider the need for the VMNET
interface to be a higher priority.  The LPR/LPD function is basically
working, however, as it shares code with the VMNET function, I continue
to find and fix occasional small errors.  Initially, we considered that
the LPD function to allow submission of print to JES2 from UNIX and PC
applications to be the major usage of the LPD/LPR protocol, however, I
found out in a meeting in Moncton NB in May that one of our partners in
the New Brunswick/Prince Edward Island regional network sees the LPR
function as being more important to allow them to route output to their
site from our MVS machine.

  In updating this note on June 7, 1990, I should add that the NJE/IP
support is basically working.  I have been able to exchange files
between JES2 and RSCS over TCP/IP using VMNET on the VM side and
my program on the MVS side.  There are almost certainly bugs that will
have to be found and excised and a couple of questions about some parts
of the protocol that may not be properly supported as they are very
difficult to test.

SYSTEM DESIGN OVERVIEW:

         +-------------++-------------------------------+
         |             ║║                ║              |         +---+
  TCP/IP | Pascal      ║║  LPD/LPR       ║  VTAM        | SNA/NJE | J |
 <-------| TCP/IP      ║║  protocol      ║  Application |-------->| E |
 ------->| function    ║║  conversion    ║  JES2/SNA    |<--------| S |
         | calls       ║║  (Exists)      ║  protocol    |         | 2 |
         |             ║║----------------║  support     |         +---+
         | runs as a   ║║                ║              |
         | subtask of  ║║  NJE/IP        ║  Separate    |
         | code to the ║║  protocol      ║  ACB/APPLID  |
         | right and   ║║  conversion    ║  for each    |
         | is driven   ║║  (Exists)      ║  NJE/IP node |
         | by TCP/IP   ║║                ║  and one     |
         | GetNextNote ║║----------------║  common ACB/ |
         | function.   ║║                ║  APPLID for  |
         |             ║║  Other print   ║  all LPD/LPR |
         |             ║║  protocols     ║  connections |
         |             ║║  (possible as  ║              |
         |             ║║   RFCs become  ║              |
         +-------------+║   available)   ║              |
                        |                ║              |
                        |-------------------------------|
                        |                               |
                        |  Primarily single task asm    |
                        |  code using a dispatcher      |
                        |  similar to that of JES2 to   |
                        |  control multiple "processes" |
                        |                               |
                        +-------------------------------+

  The idea is to do the JES2/NJE interface once then take advantage of
it as required for other TCP/IP protocols that would in a natural
fashion want to interface to JES2.  Job submission, output processing,
etc.

CURRENT STATUS:

  I have had the LPD server function working since mid-March 1990.  On
Friday, April 27, I was able to route a piece of output from MVS and
have it print on a UNIX system via NJE to my application and LPR to an
LPD server on the UNIX system.  Before this goes to production, my
management wants controls in place for accounting and authorization of
incoming LPD files, however, this will require extensions to our
accounting system which will be someone else's responsibility before I
can make use of it.

  My next step will be the implementation of the NJE/IP protocol.  In
some ways, this should be easier than the LPD/LPR protocol because at
least VMNET and JES2/NJE are speaking the same language.  The VMNET
protocol is based on BSC NJE over a CTCA while I have chosen SNA NJE
through VTAM as virtual CTCAs are not available in a pure MVS
environment.  There are some subtle and not so subtle differences in the
two NJE protocols, specifically where SCBs are placed with respect to
the first RCB in a buffer and more significantly in the "flow control"
bits of the BSC protocol which allows one NJE partner to request the
other partner to temporarily suspend traffic on some of the streams.  It
will be processing flow control that will present the biggest problem as
it will probably require that my application buffer data being sent on a
stream that the other end has suspended until the stream is once more
enabled.

  I did not receive the VMNET code from Princeton until mid-March at
which time I was heavily involved in the LPD/LPR code, however, I
had a chance to study the VMNET protocol and am convinced that my
approach is workable and should not take a great amound of additional
effort.  The SNA/NJE code is in place (for the most part) and will
require only small changes for efficiency and to provide support for
facilities which are meaningless for LPR/LPD but required for a full
NJE/IP.  The TCP/IP support code is in place and should require no
changes for NJE/IP.  It really should be just a matter of "plugging"
an additional protocol module into the program.

  In early June, 1990, the NJE/IP code was to the point where files
could be exchanged between JES2 and RSCS over TCP/IP using VMNet on the
RSCS side and my program on the JES2 side.  FASTOPEN is not yet
supported and flow control using the FCS bits has not been added.

  My reading of the BITNET II protocol implies (to me) that VMNet uses
FCS to control data from RSCS and will honour stream suspension
requested by RSCS, however, does not require that the "partner" on the
other side of the TCP/IP link do so.  If this is the case, then there is
no need to worry about stream suspension as SNA/NJE does not include
stream suspension in its protocol.  If it is possible that a VMNet might
request its partner to suspend a stream, then buffering logic must be
included that will hold back data in the suspended stream until the
stream is resumed.

  FASTOPEN is a performance option that the operation instruction
for VMNET recommends for RSCS V1 but prohibits for RSCS V2 because
of the possibility of hangs in a multi-stream environment.  Since JES2
may be a multi-stream environment, I have decided to omit FASTOPEN
for the moment.  FASTOPEN can be specified on the LINK statement for
VMNET, so it will be necessary to omit FASTOPEN from the LINK statement
for a connection to my program.  I am concerned as to whether other
BITNET II implementations (specifically, Joiner and the Israeli
programs for VAX and UNIX) implement FASTOPEN in a way such that it
can be suppressed on a link by link basis.  If not, then FASTOPEN
becomes a necessary feature and the program must have logic added to
buffer the data in a FASTOPENed stream until the permission granted
is received from JES2.  What does one do if permission is refused?

POLITICAL ENVIRONMENT:

  In Canada, we are planning to phase out our NetNorth NJE links this
summer and fall as a national TCP/IP backbone is implemented (CA*NET).
The plan requires regional backbone sites to implement VMNET or
equivalent to continue to provide NJE connectivity.  No site in our
region of the country (Maritimes and Newfoundland) has a large VM system
to run VMNET.  Dalhousie University in Nova Scotia will be running the
Joiner VMNET implementation, however, they will not be able to run
LISTSERV and the thought of trying to service all LISTSERV traffic for
our region through one NJE link between DAL and UNB is not appealing.
Our VM system is severely overcommitted to MUSIC service, however,
LISTSERV can run at a very low priority and if most Lists get "exploded"
overnight, it is not considered a problem.  I suspect that people would
not be happy if our "VMNET" service ran similarly, besides, TCP/IP is
reputed to impose much more of a load than RSCS/LISTSERV.

  It would be "nice" to have an MVSNET ready for the CA*NET drop which
is supposed to be in place in June, however, I do have my doubts.  I do
hope to have something ready before traffic begins to build again in
September.  We are having a meeting in Moncton on Thursday of this week
to plan conversion of the New Brunswick, Prince Edward Island Network
from multiplexed BSC RJE and Interactive Terminals to TCP/IP based
lines.  After that meeting, I will have a better idea of the priority of
NJE/IP within the overall strategy.

  The LPD function has received much more testing than the LPR function,
I have successfully printed files under JES2 that originated from UNIX
and PC LPR implementations as well as the LPR socket talking to the LPD
socket in the same program.  Most of the LPR testing has been between
sockets in the same program.  Only once have I actually used the LPR to
send a file to print on a UNIX machine.  The test worked with no
problems, but the file was small.  The problem with this test is that my
program has problems talking to the UNIX machines that are part of our
computing services facilities, the machine with which I was successful
in communicating belongs to the Faculty of Computing Science.  I think
the problem is mainly in the PRINTCAP file in our machine as the symptom
of the problem is a message back stating that my host is not authorized
to print or that my host is not known or (more recently) simply the
response X'01' which I believe means a problem where the UNIX machine
cannot access its printcap file or some other failure in the checking on
the UNIX end.  Our UNIX programmer is not particularly experienced and
is unable to resolve the problem.  Except for occasional favors, I do
not want to burden the Faculty's machine with my test files.

  Still missing from the LPD/LPR implementation is account validation
and checking for incoming LPD files (this probably does not concern most
installations as their requirements for accounting are without a doubt
different from ours) and support for more than simple text files.  At
present it is assumed that the file is completely formatted using the
appropriate tabs, CR, LF, FF, etc.  Outbound files from LPR are
completely formatted with carriage control (machine or ASA) converted to
appropriate LF, FF, CR combinations.  No attempt is made to reduce
blanks with tabs (I'm not 100% confident about tabs on inbound).

  The support of outbound files from JES2 to LPDs on other systems is
through standard JCL.  Output for printing will be returned via LPR to
an LPD at the remote site as follows:

    //ddname  DD  SYSOUT=A,DEST=(LPDSRV,hostname)

where hostname is defined to the LPDSRV application and maps to a
foreign host IP address and printer name (default "lp").  LPDSRV is
defined to JES2 as an SNA/NJE node and can be changed through
initialization options.  Dynamic allocation can also specify the
destination pair, so TSO applications can be written that can spin
data off the the LPR client function.

AVAILABILITY:

  Our policy (I am told) with respect to distrubution is that we do not
sell software as we do not have the resources to properly document or
support such.  We will distribute free to academic institutions with the
restriction that they not further distribute it.  We will attempt to fix
any problems that exist in our software, however, will not guarantee in
any way to do so.  Also I assume that we assume no liability for any
problems resulting from use of our software.

  If I find that there is some interest in acquiring the program then
I would put together documentation and code in a form suitable for
shipping to other installations.  In my opinion, the program is much
too large to be shipped via the network if any more than a very few
sites are interested.

  Distribution would be as one or more card image PDS with assembler
code and macros as well as Pascal code.  Included as members of one
of the library would be job streams that are used at UNB to assemble
and compile the program.  It would be necessary to change these job
streams to conform to local standards.  Documentation would also be
provided in machine readable form (DCF script as well as scripted
listings).  A cover letter would list the files on the tape indicating
which file contains installation instructions.

  We could (for the present) ship the data at 1600 or 6250 bpi tape,
however, would prefer to send cartridge tapes.  Our costs for a
cartridge tape and courier to Germany is $50 Canadian, incidental
handling costs are hard to determine.  If I had a good idea as to how
many people are interested and where, I could come up with a better
cost estimate, however, I suspect that we would not charge more than
$100 Canadian, simply to recover our costs of distribution only.
Contact me if you are interested, so that I can build a list of names
to be notified with respect to further developments.

  The program does require MVS/XA, assembler H and VS Pascal as well as
the IBM TCP/IP product, JES2 (JES3 does not, I believe, support SNA NJE)
and VTAM.

CONCLUSIONS:

  So, there you have it.  Almost a complete history with all the gory
details.  Any further questions or comments, feel free.

>==============================   Updates and notes:

1.  In July 1990,  UNB was connected to CA*Net, the Canadian TCP/IP
    based network which was replacing NetNorth (an NJE based network).
    We found that most of our NJE traffic quickly migrated to TCP/IP and
    that the remaining NJE traffic could be handled by our small VM
    system without serious degradation of service to our MUSIC users.
    We decided to lower the priority of the BITNET II code development.
    The VMNET code which had been installed on VM for testing the MVS
    version was re-configured for production use and we have been
    operating in this fashion (with a gradually decreasing NJE load)
    since.

2.  Also in July 1990 we introduced a UNIX service for our students
    faculty and staff.  Interoperability between MVS and UNIX for
    printing became more important and efforts in the program were
    concentrated in the LPR/LPD support.  We regularly have normal
    print files being sent from UNIX to MVS for printing on the large
    JES2 printers while PostScript files are sent in the other direction
    where the postscript printer is attached to the UNIX machine.

3.  Later in 1990 (or early in 1991) I received a note from Karl E.
    Kelley <GG.KEK@ISUMVS> who had been working on the BITNET II portion
    of the code and had got it working.  He made his fixes available to
    me and I incorporated most of them into my source which I had made
    available via anonymous ftp.

4.  During the summer of 1991 Rob van Hoboken
    <[e-mail]> obtained the code and found some
    problems with multi-stream support which he fixed and which fixes
    are also incorporated in the source.

5.  Also during the summer of 1991 we had problems with our VMNET
    connection to Toronto and while that problem was being solved were
    able to use the MVS program for NJE file transmission between
    Fredericton and Toronto.  The program worked adequately although a
    problem was found which was fixed by making the program
    non-swappable and I now recommend that the program be run
    non-swappable regardless of whether it supports only LPR/LPD,
    BITNET II or both.