Data Transmission from an AS400 -Reply -- MIDRANGE-L

>>> John Hall <jhall@hillmgt.com> 01/15/98 11:49am >>>
>I have to transmit a data file to a bank
>
>I have two options 1 - PC via Xmodem or 2 - Direct from the 400
>
>I prefer to send the file direct from the 400 rather than
> download it to a PC and send it from the PC.
>
>The Transmission specs are :
>        Richardson SUPERTRACS
>       Mainframe : Speed : 2400 Baud / 4800 Baud / 9600 Baud
>                   Format: EBCDIC
>                    Protocol: IBM 2780/3780
>
>        PC : ASCII / XModem CRC
>
>What do I need to do this from my 400.  I already have the com
> lines and several modems so I am ok on the hardware end.
>
>This is to be a daily transmission & we will need logging to confirm
> the transmission of the file and notification if the transmission fails.

                      ----------

I've set up several transmissions to banks but can not claim to be a
communications guru.  Thus, everything I write here is based on what
I've gotten to work in the past, but I couldn't tell you really all the
ins & outs of why it works (I'm sure there are wiser heads on this list
who could explain why things are the way they are better than I.)  
I've always used the following setup:

1) BSC type line, controller, & device description created on the
400.  Creating those properly requires some input from the
receiver (the bank), e.g. telephone # to dial, baud rate, record &
block length expected, etc.  There's alot of more esoteric parms on
the CRTxxxBSC commands (like contention resolution winner,
seperator character, clear to send timer, etc.) that I've always
accepted the 400 defaults for and always had them work OK.
2) An ICF file to connect a program to your newly created
communications config.  This file is created from normal DDS specs
using CRTICFF command.  You connect an ICF to the device description
using the ADDICFDEVE command.  Typically, I have several record
formats in this file's DDS:
- a control or signon record thru which you send an identifying
signon string to the receiver (signs you on to the banks system/
SUPERTRACS - the bank has to give you this string)
- a data record for the detail data you're transmitting.  You can field
describe this in the ICF file or just have it be a single field & build
the record in your comm pgm.
- an ENDGRP record using the ENDGRP DDS keyword.  Near as I can
tell, this is sort of a <CR>/<LF> for communication processes,
telling the receiver to stop expecting data and "turning around" the
conversation - I'm probably all wet on that, but I know it works.
- an EOS record using the EOS DDS keyword.  This has always been
the last record I send & I take it to mean "I'm all done, bye bye now"
3) A pgm to write data to the ICF file.  This simply writes to your ICF
file just as though it were a database file - OS/400 takes care of
sending the bytes you write out the comm port.  I usually follows the
following skeleton format:
           SETUP
           WRITE <signon record>
01N01  WRITE ENDGRP
           LOOP OVER DATA TO XMIT
           WRITE <data record>
           END LOOP
01N01  WRITE ENDGRP
           WRITE ENDGRP
01N01  WRITE EOS
the "01N01" are RPG indicators - I don't know why they're needed,
especially since the condition of indicator 01 being on and off at the
same time will never occur so that WRITE is never really executed,
but it's needed all the same and does work.

HTH
Scott Cornell
Mercy Information Systems
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---