[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference help::osi_appl_support

Title:	Please read note 1.0ELP::OSI_APPL_SUPPORT
Notice:	Please read note 1.0
Moderator:	DRAGNS::MILLERCOM::S_WATTUM

Created:	Mon Aug 30 1993
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	516
Total number of notes:	2729

512.0. "Record length question" by COMICS::HESS () Thu May 22 1997 11:43

Hi,
	I would like some help with the following issue, I am unsure of our
implementation of FTAM and record formats.
	A customer is receiving a file from an ICL  and expecting the
recordsize to be 2626, however the first record is 5252, all the other records
are ok, here is what appears to be happening from a responder trace.( I have
only put the record headers here)
1st record.  
04821494 39800482 07f8
ICL's interpretation of this is 
04821494    data of 5268 (2x2626 + overhead)
3980	    General string of indefinate length
0482 07f8   Data of length 2040

then follows data of length 2040   Then
0482 024a	Data of 586 which is a continuation of the first record
 then follows the data and at the next record
00001982 0a42  	
Which ICL say 0000 indicates end of construction and 1982 0a42 is a general
string of 2626   (the second record)
all the other records are constructed as follows
0482148c 19820a42   and are handled by us as records of 2626 length records.
	ICL claim ( and I have not enough knowledge in this area to disagree)
that although the construction of their first record(s) are different from the
others there is nothing wrong with it and we should recognise the 00001982 0a42
as the second 2626 byte record .
	Are they right and if not where do we document this restriction ?
Thanks for any input
Pete

T.R	Title	User	Personal Name	Date	Lines
512.1		RMULAC::S_WATTUM	Scott Wattum - FTAM/VT/OSAK Engineering	`Thu May 22 1997 12:30`	15
	Could you please provide a pointer to a complete FTAM trace showing the file transfer, it is very difficult if not impossible to understand the problem or provide an answer without looking at the entire trace. In addition, we need to the complete trace in order to try and reproduce this. I swear, I think I'm going to start doing really off the wall data encodings in our FTAM just to drive other vendors nuts too. Where do they come up with this stuff? Constructed strings - sheesh.... Without the trace and without reviewing the standards involved, I would say that ICL might be correct and we should be handling this differently. Get an IPMT entered along with the trace and we can look into it further. --Scott
512.2		COMICS::HESS		`Thu May 22 1997 13:07`	6
	Scott, I will raise an IPMT, if you have a location I can copy the responder trace (analysed and unanalysed) to you. Thanks Pete
512.3		RMULAC::S_WATTUM	Scott Wattum - FTAM/VT/OSAK Engineering	`Thu May 22 1997 13:20`	2
	You can push it to DRAGNS:: and send email to DRAGNS::WATTUM when it's there.
512.4		RMULAC::S_WATTUM	Scott Wattum - FTAM/VT/OSAK Engineering	`Wed May 28 1997 11:15`	4
	Well, I've gone thru the standards again, and the encoding ICL is using does appear to be legal. I still find it incredible that anyone would actually do an encoding like this. This might be a nasty one to fix in FTAM, I doubt we ever anticipated that someone would actually desire to do this.
512.5		COMICS::HESS		`Wed May 28 1997 13:35`	5
	Scott, Thanks for confirming that they are at least doing something that is valid, the ipmt will be with you soon. Pete.
512.6		RMULAC::S_WATTUM	Scott Wattum - FTAM/VT/OSAK Engineering (303) 840-2986	`Thu Jun 05 1997 20:06`	2
	This problem has been resolved, and a new osif$fal.exe provided to the field. The fix will be included with the DECnet-Plus 7.2 FTAM.