View Full Version : ICF program problems
01-01-1995, 02:00 AM
I have recently written a fairly basic RPG communications program to send a couple of data files to one of our customers using an ICF file and Bisynchronous communications. I ran into a few glitches that I think have to do with the way I am blocking the transmitted data. In any case, I decided to try set up another RPG program on our AS/400 that would read the data that I was transmitting and that way I could work out my program bugs internally instead of relying on coordinating with our customer. The new program I have written should perform multiple read operations on the ICF file that I created for the program, and then output the data that has been read into the ICF file to a data file. I submit this program to batch before starting my original program and it executes until it reaches the very first read operation to the ICF file. At this point the program just sits and waits for input. At this stage, the line has a status of Connect Pending. The controller and device both have a status of Vary On Pending. My line description for this program device is set up for AUTOANSWER and the controller description is set up for an initial connection of *ANS. This is just as I would expect. Once I start my original program, it executes until it reaches the first write operation to its ICF file. At this point, the modem associated with this ICF file dials out to the other modem associated with the program above. The other modem picks up but then nothing happens. The program hangs on that first write operation, and the first program that I started hangs on the read operation. I was expecting that the records that I was writing from the one program would be read by the other. Where have I gone wrong? This is my first attempt at a communications program so I may be missing something obvious.
06-13-2000, 06:20 AM
Usually, the ICF program will dial out then EVOKE a program to start, then once a connection is made, start writing records. What does your ICF file definition look like?
06-13-2000, 04:47 PM
The two ICF file definitions used in my two programs are very basic. The program that does the sending has two record formats - since I am sending data from records that are 125 and 250 bytes long. The program that does the receiving has a single record format for receiving data, with a record length of 250 bytes to accomodate either of the two sized data strings transmitted. I am not evoking the "receive" program (although I'm sure that would work also) but rather am submitting a batch job to start the "receive" program. I did uncover something however at the end of the day today. The line description for the ICF file in my "receiving" program has a parameter called "RCVTMR". It is set to 50, which translates to 5 seconds as being the amount of time the ICF file will wait to receive data before timing out. Since the very first operation performed on the ICF file in my "receive" program is a READ, I wonder if the line isn't just timing out and that's why it appears that the job is hanging when I attempt to do my first write from "sending" program/read into "receiving" program operation. Maybe all I need to do is to execute a write to the ICF file in my "receiving" program BEFORE I issue a read to the file. That way the program will be waiting on the write operation rather than on the read operation and so will not time out. I didn't have time to test this before I left the office today but will do so tomorrow and let you know how it turns out.
06-14-2000, 05:53 PM
My idea to issue a write to the ICF file in my "receiving" program before I do a read did NOT work. The program is still hangs whether the first operation to the ICF file is a write or a read. I am at my wits end and am ready to give up. I KNOW that my sending program is OK because I can send data to my customer (although there are errors with the transmission). I just cannot send at all to another program on my own AS/400. Any more ideas?
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.