I am creating a variable record length file via Lawson custom program (COBOL). The organization receiving the file requires spaces as fillers on the end of some of the records. My problem is, the "tape" file format is truncating the record length down to the last character of meaningful data and will not include the spaces on the ends of the records. Does anyone have a suggestion on how to force each record to maintain its full length?

Thanks,
Dan

Sorry. I thought I responded to this already - but do not see my response. Please ignore if duplicate message.

Let us say your record size is 400 bytes, place some non-blank character in the 400th byte before you do your COBOL WRITE.

Ragu

So then how do I remove that last character before I transmit the file to the recipient?

Have you considered writing a script and calling it using CALL "SYSTEM" after you close the file? Its not great but its a solution.

Do you know if the truncation is happening during the file transfer or when the file is generated. I know ftp sometime does this. I could have sworn there was a file type that prevented this sort of thing. I'd have to look back through some old code.

I do not think you need to get rid of the last character. You did mention that the origanization at the other end expects spaces as fillers. A filler is typically ignored by the processing progam.

So let us say, in a record size of 400 bytes, you have meaningful data ending at byte 256, their program probably has a field definition that says FILLER byte 257 thru 400 and will ignore any data in that range.

I have done this with at least two benefit providers with no problems.

The records are being truncated as the records are placed into the file. I may have to resort to a script to correct the record lengths. But then again, maybe they won't care if there are extraneous characters at the ends of the record beyond their required length.

Thanks to both of you for your help,
Dan

Hey all

Sorry to be coming into the converstion late but we found a way to solve this problem using CSV type. however we don't use the field separator. This is a way you could do it w/o having to hope they don't look at the fields that should be recognized as blank/filler. Check out the file attributes on the workdef example below. hope this helps a litttle.

I've run into the same extact problem although I have a trailer record to write in my export file as well. This forces me to use tape as a format instead of CSV without commas. I figured that I would just put an extra character at the end of the normal record like a period or letter to force it to the right length as they mentioned in earlier replies.

This is "standard" sideeffect of using the TAPE format. Lawson drops the trailing spaces at the end of each line when writing the file. In most cases I've run into this is actually not a problem - the reading program accepts the file a-OK, as the reading system just fills back in those spaces for you. If you haven't tried this give it a shot as it my eliminate your need to force those spaces onto the end of the file at all.

BUT, if you've tested this and the receiving system "complains" about the missing chars, I would suggest a couple of things:

Similar to what is already being suggested - placing a character in the very last (the example arbitrarily used was) position 400 will 'force' Lawson to write the full length of the file. Hopefully the receiving program will not care about this miscellaneous character since it wasn't expecting data anyway.

--> a small modification to the above would be to write the character in the 401 position and then use the UNIX "cut" command to remove it. If you have a file called "test_file" then the command "cut -c 1-400 test_file > test_file2" would effectively cut off that 401st char, resulting in a fixed-length file.

Another way to do this would be to change your file format from TAPE to SEQUENTIAL. That will produce the fixed length you're looking for HOWEVER, it will be all one really really long line as there are not CR/LF chars in a SEQENTIAL file. Lawson does provide a nice utility to work around that. 'cnvexp' and 'cnvimp' are sister utilities that will remove or add return characters from text files to convert them from and to LINE SEQUENTIAL(TAPE) and SEQENTIAL. In this case you would run the command 'cnvexp -f test_file 400'

Hope that helps!

This is "standard" sideeffect of using the TAPE format. Lawson drops the trailing spaces at the end of each line when writing the file. In most cases I've run into this is actually not a problem - the reading program accepts the file a-OK, as the reading system just fills back in those spaces for you. If you haven't tried this give it a shot as it my eliminate your need to force those spaces onto the end of the file at all.

BUT, if you've tested this and the receiving system "complains" about the missing chars, I would suggest a couple of things:

Option 1) Similar to what is already being suggested - placing a character in the very last (the example arbitrarily used was) position 400 will 'force' Lawson to write the full length of the file. Hopefully the receiving program will not care about this miscellaneous character since it wasn't expecting data anyway.

Option 1a) a small modification to the above would be to write the character in the 401 position and then use the UNIX "cut" command to remove it. If you have a file called "test_file" then the command "cut -c 1-400 test_file > test_file2" would effectively cut off that 401st char, resulting in a fixed-length file.

Option 2) Another way to do this would be to change your file format from TAPE to SEQUENTIAL. That will produce the fixed length you're looking for HOWEVER, it will be all one really really long line as there are not CR/LF chars in a SEQENTIAL file. Lawson does provide a nice utility to work around that. 'cnvexp' and 'cnvimp' are sister utilities that will remove or add return characters from text files to convert them from and to LINE SEQUENTIAL(TAPE) and SEQENTIAL. In this case you would run the command 'cnvexp -f test_file 400'

Hope that helps!

Actually, I just noticed you were talking about a variable length file, which makes the above not 100% (if at all) applicable. Go ahead and try the test above I mention hoping that the accepting system will just accept the missing chars be replacing them for you. OTHERWISE you've got a challenge. I'd suggest using Option 1 above, sticking a sequence of chars onto the end of the file to force the appropriate length and then run an 'awk' command to search and replace those sequence of chars with null, effectively removing the values. (by sequence of chars I mean something that would NEVER otherwise appear in your file, such as "#!QQxR0" or other random sequence). You should be able to do this right from within the COBOL code using a CALL "SYSTEM" USING WS-COMMAND where WS-COMMAND has the awk statement within.