PM>> Since the function is user supplied, it can do any thing you want. This

 PM>> could be updating an OS/2 PM window or communicating with another

 PM>> machine.



 PE> To communicate with another machine via SRPI, you need to actually end

 PE> your program, and return the the assembler program which called you.



But does anyone actually use SRPI?



 PM>> Well, for a start, you shouldn't be constantly polling anything. All the

 PM>> user supplied function should be doing is to updated the display and

 PM>> checking if the transfer needs to be aborted



 PE> It also needs to send data to the comms port or whatever you happen to be

 PE> using to send the data using Zmodem.  Naturally whether it is a comms

 PE> line, a vsam file, or a unix pipe, has nothing to do with Zmodem.



It doesn't matter whether the calling routine is doing all the work, or a
routine that the Zmodem code calls, the same things need to be done.



 PM>> What's really going to decide the issue is where the Zmodem routine gets

 PM>> it's data from. If you have a routine that calls it with some data to

 PM>> transmit, then the Zmodem routine will need to return after processing

 PM>> the data. Therefore, the calling routine should probably be the

 PM>> one controlling the display etc.



 PE> Yes, perhaps I'm getting the data from an indexed vsam file rather than a

 PE> sequential file, so I'm using low-level assembler macros or something.

 PE> Once again, Zmodem shouldn't care where I get my data from, it should be

 PE> provided by the caller.  I wonder how small you could get zmodem down to

 PE> if you got rid of all the crap like file handling which has NOTHING to do

 PE> with the Zmodem protocol.  Oh yeah, and when you get a filename clash,

 PE> what do you do, etc etc (perhaps you want to ask the user what he wants

 PE> to do).  Certainly all this has nothing to do with Zmodem, and the Zmodem

 PE> routine should just define the protocol.  So how would you do that?





From memory, the file name is send to the receiver. In your senario,
presumably the zmodem receive routine is returning to its caller after
every block so that the data can be written somewhere. The routine calling
the receive routine could then be the one to decide what to do with a name
clash.



Since I don't have a copy of the protocol description, I don't know whether
it's valid for the receiver to reject the file name. It may be that there
is no way to notify the sender that there is a name clash. In this case the
receive will have to do its best.





Paul



--- GoldED/2 2.42.G1114