Fm: Tony Anderson 76703,4062 To: Carmen Paone 72677,42 (X) Ah, I see you've mastered the art of the Xmodem upload ... almost. Both files arrived, and they checksum Ok. I can tell that you used Xmodem for the upload, or one of the other error-checking protocols, if you used a PC or some other machine. How, by the length of the lines in the file, several of which exceed the input buffer's size limit of 132 bytes. i.e., the lines are longer than 132 characters, without a carriage return. In other words, you composed the file in your computer using automatic word wrap, and did not embed carriage returns in the text so that it would be printed properly when listed to paper. Each "paragraph" is one long line. Since Xmodem sends exactly what you've got, it uploads it that way, and is stored that way here. Problem with that process, is that many folks who read the file (or download it), and echo it to paper, have a problem with the file in that form. Their printer starts at the beginning of the line, and prints along until it gets to the 79th character, then it prints the rest of the paragraph, no matter how long it is, at the 80th character position. It makes a nice black square at the end of the line. When it gets a carriage return, which you designated as "end-of-paragraph", it reads it as "end-of-line", and goes back to the left margin to print the second line(paragraph). Makes it real hard to read in that form. - Alternately, some printers will just print right off the right side of the paper, and everything beyond the 80th character (or whatever) in each paragraph is lost. So whenever you upload with Xmodem, especially a text file, or a file that contains textual materials, you have to be sure to format the text first, so that it will print properly on such printers. I have downloaded both files and will reformat them offline, then reupload them for you. But next time, we'd like you to do it yourself. Ok? The files will be available late tonight, as usual. Fm: Carmen Paone 72677,42 To: Tony Anderson 76703,4062 (X) Thanks, Tony. I will download your message and use it for my next XMODEM upload. Sorry for the extra trouble, but I used my ROM/Cleaseau to make the lines as packed as possible. Now I'm wondering if it was worth it for the sake of a program that is 100 bytes or so smaller? Oh, well, live and learn! #Carmen# Fm: Carmen Paone 72677,42 To: Tony Anderson 76703,4062 (X) Tony, I uploaded an experimental program to see if I could beat the CIS buffer limit. It's no coincidence that the program was designed to help me and others keep their lines of text under 132 characters. Let me know how the file came through. HEADS.BA also will be uploaded tonight. #Carmen# Fm: Tony Anderson 76703,4062 To: Carmen Paone 72677,42 (X) Here is Line 1 of the CIS132 program, exactly as it arrived: 1 CLS:MAXFILES=1:F$="CIS132.DO":OPENF$FORAPPENDAS1:RV$=CHR$(27)+"p":NV$=CHR$( 27)+"q" Note that it has been broken at the leading paren in the end equation. Please check your original file to see if that's the way it was in the file. If not, then there is an upload problem somewhere along the line. It may not be your fault, there have been formatting problems in CIS software before. I can fix the above problem here, no need to upload it again. All of the program lines in HEADS.BA are fine; some of the text lines are longer than 80 characters, some are less than 80. I can edit the long lines and still maintain the checksum, so there will be no need to upload that again. Thanks. It will be available by morning. Fm: Carmen Paone 72677,42 To: Tony Anderson 76703,4062 (X) Thanks for the fixes. Let me get this straight. Program lines should be less than 80 characters, and text line should be less than 132 characters. If that's the case, I use CIS132 as CIS80 when I writing program lines _ just to make sure I'm within the limits. This sure has been a mystery to me. But it also has been a learning experience. Thanks, prof #Carmen# _ awaiting the final exam. Fm: Tony Anderson 76703,4062 To: Carmen Paone 72677,42 (X) No-no-no-no-no. The CIS input buffer accepts lines of 132 characters or less, it matters not whether they are "program lines" or "text lines" - to CompuServe, it is ALL "text"; or "characters" if you will. CIS doesn't care what the characters are trying to _convey_, what their _meaning_ is. The reason we ask that TEXT be formatted for 80-column width, is to accomodate those who have printers that will print long lines up to the 80th character, then will print the rest of the line at the 80th character position, typing additional characters over and over on top of the 80th character. This results in only the first 79 characters of the line being readable. This is a particular problem with text files that are composed without any carriage returns in the file, and which are uploaded with Xmodem or one of the other error-checking protocols which ignore the printer's need to have carriage returns embedded in the text so it won't jam up at the right margin. The size of CompuServ'es input buffers have nothing to do with it; it's an accomodation for folks who echo files to their printer. Obviously, if some of a line is unreadable, the information conveyed in the file is unusable. Some printers will print right off the right edge of the paper, instead of jamming up at the right margin - again, those folks who have such printers lose the information they can't read. So we recommend text files be formatted for 80-columns, or "Width = 80" for that reason. Some folks have printers that will automatically word-wrap at the end of a line, at the 80th character. If your text lines are exactly 80 characters long, this creates an extra blank line on such printers, one created by the printer for the word-wrap, and one actually created by your text. So in generic terms, when we say "80-column width" we don't mean 80 actual columns, but formatted to print on 80-column printers, which, in practical terms, means formatted to 78 or 79 columns, to allow for those printers which feature automatic word-wrap. Width=78 will accomodate all printers - except those which are 64-column or 40-column printers; thankfully, there are few of those around now days. So "80-column" generically means 78, the recommended width for text files. In the past - the "early days" - text files were separated from program files, a program that required instructions or "documentation" as some prefer to call it, required a separate file for the text material, separate from the program material. Lately, it has become common practice for the author to include a few lines of instruction or comment along with a program in a single file. Unfortunately, that can be traced back to me, since I was one of the early library contributors who included several programs and commentary in a single file, to keep everything together. Before I started doing that, it was never done. On multi-program situations, such as spelling checkers, or membership auditing programs, you had to download a bunch of separate program files, and follow extensive .DOC instructions to pull them all together and make the "system" work. We learned early-on that many Model 100 users were not highly technical, computer-savvy, users. If a program they downloaded had an extra carriage return in a line and wouldn't run, they didn't know how to fix it. (No reflection on them, not everybody is computer literatre.) So the forum administrators at the time determined that there would be no programs allowed into the library that had to be "fixed" before they would run. This lead to problems, since program lines could be longer than 80 characters; up to 255, in fact. And this ran into a second problem, because CompuServe's input buffers were only 132 characters. Most programs can be written to accomodate the 132 character line length, but why should we have to rewrite programs to accomodate such a restriction? The answer was to upload files with the Xmodem protocol (or any of the error- checking protocols), since you could then ignore the length of lines, since Xmodem sent up exactly what was in the computer doing the upload. So lines longer than 132 characters were now possible - programs which had such long lines could be downloaded directly into the computer, converted to BASIC, and would run without loading errors. (which some non-techie, early users, considered to be "bugs", and so reported them... "The program must have a bug in it, it won't load into BASIC...") Now, however, we get back to the printer problem... How does a printer that is limited to a line length of 80 characters, print a line that is 175 characters long? The answer is simple - it doesn't. Too bad. Programs were not meant to be listed on paper, they were meant to be loaded and run in the computer. We can accomodate one or the other effectively, but give us a break, we can't deal with everybody's printer on an individual basis... So combining text and programs in a single file, where the program lines exceed 80 characters is possible, it just isn't a good idea. Doesn't mean we can't do it, or that it still doesn't happen, because a lot of people who contribute to the library are not aware of the limitations or problems when dealing with the needs of a large, diverse group, with different types of equipment and expertise. So we do the best we can - in files which combine text and program lines, we ask that the text be formatted for the printer - so the user can at least READ the instructions, and that the program be formatted as necessary to prevent conversion or running errors when loaded into BASIC. Hopefully the program lines can be cut out of the file (after download), and pasted into BASIC, and will run. Unfortunately, you're one of the writers who combine the disparate file types in a single file, and we've had to deal with the results over the last few days, as you've seen. There's nothing wrong with the approach, it just brings special techniques to bear when you try to accomodate all the limitations, and in order to deal with the resulting problems. Obviously, none of your former contributions ran into these problems. Fm: Carmen Paone 72677,42 To: Tony Anderson 76703,4062 (X) It seems to me that a separate DOC file would be a better approach. The reason I include DOC and programs together is too present them as one package. I reasoned it would cut down on the amount of time it would take to download the package. I can see that the couple of seconds of difference between downloading one large fi isn't worth it when you consider the formatting problems that you have outlined. If the file isn't readable on paper after being printed, it isn't of much use to the user who downloaded it. And, hence, he has wasted his download time and money. Tony, please consider doing a help file (if one dosen't already exist) on ways text files could be properly formatted for uploading to CIS. Regards, #Carmen# Fm: Paul Globman 72227,1661 To: Carmen Paone 72677,42 (X) Carmen - For the same reasons you mentioned, I often combine the docs with the program in the same upload. But when I create the _docs_ I make sure it's formatted, with hard carraige returns in the file where I want them and I make sure that lines of text never exceed 79 characters. For BASIC programs, when I write them I try to keep program lines at 39 characters so it is easy to view on the LCD. If they are small I leave them with a short line, but if the program is lengthy I use Cleuseau and do MIN120 (rather than 132). Then I save the program as ascii and merge it with the docs. Next I checksum the combined file and when I upload it, since the line length is the way I want it, I simply press ENTER at the "width:" prompt. Even though the CIS buffer takes 132, I see no reason to push it to its limit and lines of 120 are sufficient. Best, Paul Fm: RANDY HESS 73267,552 To: Carmen Paone 72677,42 (X) Carmen, A few of the programs I've uploaded recently had both the "DOC" text AND long BASIC lines included in the same file. I can do this because I use Van's ZIPFMT.CO program to format the text file to 78 columns then I tack on the BASIC lines and upload the "set" using XMODEM. Like you, I felt that for a small program it made sense to put it all into the same file. Since Uload time is free, using XMODEM is worth the extra effort (plus CIS is certain to receive what you send!). Tony's advice about line lengths and CIS is certainly worth saving. The printers I've had experience with will even usually "wrap" long BASIC/TEXT lines that aren't formatted but there must still be some that won't. Don't forget that you can use the 200's print formatter with BASIC programs in the "Edit" mode too. (oops, do you have a 200?) Good Luck, Randy Fm: Tony Anderson 76703,4062 To: Carmen Paone 72677,42 (X) That's why I started including instructions or doc's in small files - it was easier to upload one file than two, and it was easier for folks to find the whole package, rather than coming back and asking "are there any instructions for this program?" I think the file you mention is already there; called UPLOAD.HLP in Library 1. We often forget about the help files, but there is a whole bunch of them contributed over the years in Library 1. They all have the .HLP extension, so it's easy to find them with the SCA *.HLP command. The file may not be up to date with the latest software changes - which, by the way, happened earlier this week, in case you all missed it. But I've found that trying to keep up with documentiong the changes is like chasing the wind. Better to send folks to the practice forum, where they get paid to deal with the changes and helping folks find out how to use them best, at no charge.