ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

I am having a problem creating files in RMCobol. I am trying to create line sequential TXT files for transfer to a dos server. The progtram bombs with an unexpected character that can not be accepted in a Line Sequential file. Is there any way around this?

The files are on a Red Hat Linux system and they are TRUE TYPE data files. The true type format is Black Serif 9 Point. The data is a carry over from an old NCR system. It was moved to Linux box in 2001 and the file type was never changed. Is there any way I can scn the records for bad data prior to copying the records out. When i load the records as a straight sequential file I get a record length of 3,192 bytes. There are 6 records on each line with not ending CR or LF. Any help will be greatly appreciated.

The absence of CR/LF on each and every record is, of course, what's clobbering the software's expectations, and therefore, unfortunately, the software.

If possible, try to trace the problem up-stream to its root cause: there must be an explanation somewhere as to why those records are "different." The main reason why I say this is that, well, a digital computer executing (bug free(!)) software really doesn't know the word, "different." (There is no if..then..else..but_every_so_often statement that I know of, or want to.)

You could, of course, "fix" the file, although I wouldn't spend too much time in COBOL doing what presumably could be done with a script in another language. But, y'know, in order to "fix it," you'd have to have a bright-line rule, such as all computer-software requires. And this file, "inexplicably" ... well, it really just comes down to "inexplicably."

You've got an inconsistent input-file. That means that somewhere out there you've got an inconsistent (i.e. "buggy") program that's producing it. Unfortunately, that's inexcusable. Your program, presumably, is working correctly, and is sounding an alarm that just can't wisely be ignored by the business.

The problem is definitely the missing end of record characters. I am now creating the file as strictly sequential and I insert @@ characters at the end. I then use sed --e 's/@@/\xOA/g' file1 file2 to replace the @@ with hex OA which is LF in Linux. I seems to work. On the last go around though it is displaying all the records. Why I don't know! Can you help.

The answer to the problem lies in the creation of the file. Depending on the type of data stored, be it packed or nonpacked, the created file will either be sequential or line sequential. The former type will have two disrincty characters added to it which are to be replaced by a hex 0A using sed. The latter will have a 'CR LF' inserted using unix2dos -c ascii File1. These can then be FTPd to an i series or windows system.