× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: scs2ps
  • From: Jason Felice <jfelice@xxxxxxxxxxxx>
  • Date: Wed, 27 Dec 2000 14:37:49 -0500
  • Organization: Cronosys, LLC

Rich Duzenbury wrote:
> 
> Hi everyone.
> 
> I hacked together an scs2ps (SCS to postscript) program today.  Very
> experimental (read: not well tested).  It was kind of a fun afternoon
> project, and it appears to work ok so far.
> 
> I'm pretty unclear as to what I should do with it now.  I've never worked
> on an open source project, and I've never (before today) written C code on
> Linux.  In fact, up until today, I hadn't written any C since about 1991 or 
>so.
> 
> So, a few "open source etiquette" questions:
> To whom should I send the source code to?  The list?  Scott or Mike?

"Standard" Open Source etiquette (at least according to Linus Torvalds
and some others, and strongly agreed with by myself):

1) Post in patch form if at all possible.  Even if you are posting a
completely new source file, a patch against the distribution makes sure
it goes in the right place.
2) Use `diff -u' form patches (You'll need `diff -ur' to recurse
subdirectories to make a patch against a whole distribution, or `diff
-ur --new-file' to produce a patch that creates new files).  These
universal-context diffs are easy to read and verify the correctness of,
and in my experience are resilient to mailer-munging.
3) Send small patches (say <= 200 lines) to the list so that anybody who
wants to can try it out.
4) Put larger patches on some Internet accessible site, preferrably
accessible with http or ftp.  Post the URL to the list. (Some people say
gzip it and attach it to an email, but some mail readers can't deal with
that sort of thing.)
5) Make sure the patch applies cleanly.  Note the version that patch is
against in the posting.  Some maintainers, particularly busy ones, will
chuck a patch without looking at it if it fails to apply.  Applying with
some `fuzz' messages is usually okay.
6) Your patch shouldn't try to patch machine-generated files (like
`configure'). The rationale is that it will cause applying the patch to
fail if the maintainer has a different version of the tool that
generates the file.

> 
> What should be in the copyright notice?  What I did was copy the
> scs2ascii.c module that Mike wrote, SED'd all the function names from
> scs2ascii_ to scs2ps_, and then mashed up the existing functions, plus
> added some new ones.  So, the bulk of the program is Mikes code, with a
> pile of changes by me.

Hmm, it might be wise to keep Mike's copyright then.  It gets into a
grey area every now and then, but the general rule is to put your name
on files you write from scratch and keep the original copyright holder's
name on files that you modify.  So long as it's all GPL, none of the
authors will care unless you are effectively stealing the credit for
something.  BTW, your patch should also add yourself to the `AUTHORS'
file (with email address if you don't mind) and note modifications in
the `ChangeLog'.

> 
> Also, this project probably won't reach it's full potential until I can get
> my hands on the specs for the SCS data stream.  What docs I found on the
> internet, and what the AS/400 produces are not nearly alike.  So, I submit
> yet another plea for detailed specs on SCS.


Here's a little bit of info:
http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QB3AUJ03/APPENDIX1.5.1

I'm not well versed in IBM hardware, but if I were, the next thing I'd
do is get the model number of the newest whiz-bang SCS printer and see
if it has a functions reference online at http://publib.boulder.ibm.com
.

I looked at www.rfc-editor.org and looked through the 5250 RFCs.  There
is no reference to SCS in them, but one of the footnotes of the newest
RFC refers to the "IBM Pageprinter 3812 Programming Reference" as a
source.  This might be the thing to look for.

There were some drafts of revisions of the 5250 RFCs which had yet to be
published.  I can't find them now, but these might contain some info
(I'm not sure if they were ietf drafts).

> 
> Regards,
> Rich
> 

Good Luck,
-Jay 'Eraserhead' Felice
+---
| This is the LINUX5250 Mailing List!
| To submit a new message, send your mail to LINUX5250@midrange.com.
| To subscribe to this list send email to LINUX5250-SUB@midrange.com.
| To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.