Cobol - SOURCEFORMAT AND COPY LIBRARY

Author

SOURCEFORMAT AND COPY LIBRARY

apknight

2005-03-07, 8:55 pm

sorry. my english is very poor. so my text is not proof reading -_-a

If SOURCEFORMAT was FREE, Copy text was Fixed?

example:

$ SET SOURCEFORMAT "FREE"

IDENTIFICATION DIVISION.

PROGRAM-ID. Aroma96exam.

*STUDENT NAME .................................................

*STUDENT ID .....................................................

ENVIRONMENT DIVISION.

INPUT-OUTPUT SECTION.

FILE-CONTROL.

DATA DIVISION.

COPY "abc.txt".

..............

abc.txt was fixed or free?

01 dat1 pic x(10). <-?

01 data pic x(10) <-?

LX-i

2005-03-07, 8:55 pm

apknight wrote:
> sorry. my english is very poor. so my text is not proof reading -_-a
>
>
> If SOURCEFORMAT was FREE, Copy text was Fixed?
>
>
> example:
>
>
> $ SET SOURCEFORMAT "FREE"
>
> IDENTIFICATION DIVISION.
>
> PROGRAM-ID. Aroma96exam.

I'm not sure what compiler you're using, but the one I have (Fujitsu)
has settings for "Source Format" for both the program, and the copy
texts. Check the compiler's manual and see if SOURCEFORMAT can take two
arguments. :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Russell

2005-03-07, 8:55 pm

LX-i <lxi0007@netscape.net> wrote in news:afdb7$422c4e68$45491f85$25530
@KNOLOGY.NET:

> apknight wrote:
>
> I'm not sure what compiler you're using, but the one I have (Fujitsu)
> has settings for "Source Format" for both the program, and the copy
> texts. Check the compiler's manual and see if SOURCEFORMAT can take
two
> arguments. :)
>
>

Another option would be use a format in cpy files that works
with both free and normal. Eg, columns 01-06 are blank (only), never go
past column 72, comments are marked by an "*" in column 07, and a ">" in
column 08. You are not allowed to put "-" in column 07 (or anything else
but spaces as well).

Start paragraph names in column 08, all else in column 12.

Have I missed anything?

This should work whether or not you are in "free" mode or not.

James J. Gavan

2005-03-07, 8:55 pm

apknight wrote:
> sorry. my english is very poor. so my text is not proof reading -_-a
>
>
> If SOURCEFORMAT was FREE, Copy text was Fixed?
>
>
> example:
>
>
> $ SET SOURCEFORMAT "FREE"
>
> IDENTIFICATION DIVISION.
>
> PROGRAM-ID. Aroma96exam.
>
>
>
> *STUDENT NAME .................................................
>
> *STUDENT ID .....................................................
>
>
>
> ENVIRONMENT DIVISION.
>
> INPUT-OUTPUT SECTION.
>
> FILE-CONTROL.
>
>
>
> DATA DIVISION.
>
> COPY "abc.txt".
>
> .............
>
>
>
> abc.txt was fixed or free?
>
>
>
> 01 dat1 pic x(10). <-?
>
>
>
> 01 data pic x(10) <-?

I assume you are using a Micro Focus compiler. I think, (but could be
wrong), that they are the only ones who use $set to indicate Directives.

Whether or not you use fixed or free format I think is just a personal
preference. I prefer fixed giving me a margin around my text, which I
find more 'pleasing' - and using 'portrait' (8.5 x 11), there is room to
use a three-hole punch so that you can put source into a binder. (Not
that I do that - but the facility is there).

Back through the 60's-80's on mainframes with print barrels that gave
only Uppercase then free format would have been useful. The 80 column
maximum meant that printing on continuous 11 x 14 there was a fair
amount of paper wastage on the right side of each sheet.

You can (assuming Micro Focus again), use free format with a maximum
line of 250 characters. Now try and print it out - you would have to
select 'landscape' and chances are you will finish up with a fair amount
of wastage on the right, yet again.

Never tried it - but do you have to put that very first $set
sourceformat "free", starting in Column 7. Presumably all subsequent
lines can be coded to the extreme left starting at Column 1. Again no
knowledge of it, but I would have thought copy 'abc.txt' also starts in
Column 1 - although if using free format, aren't the rules relaxed about
column positioning, with a compiler ignoring preceding spaces in any one
line ????

The real practical use I have seen for free format is reducing the
amount of space taken up in a text book, where the author has the source
as a table of two columns. (Yes of course using laser printers you can
even get more than one page of source on a sheet - so one sheet of paper
can, front and back contain four lots of source. Trouble with that,
unless your eyesight is very good - you can't read it easily).

A possible tip if you are using Net Express. There are many occasions
where utilties, copyfiles can be used with more than one applicaion. My
approach I put the 'originals' in an application 'copylib' - within
individual projects I will then have say DateRoutines.cbl - within the
current project there is a three-liner :-

*>------------ DateRoutines.cbl--------------
copy "\coplylib\DateRoutines.cbl".
*>--------------------------------------------

I have to compile the above within the current project - but it is at
least referencing the original source which can also be used by other
applicatons. If I have applications using common copyfiles, then you
will see an entry in the appropriate source :-

copy "\copylib\dates2.cpy".

One immediate reaction from others here might be, the approach is
half-assed - produce a copylib DLL - but I don't necessarily want a DLL
covering ALL that is in the copylib - the current application may only
use 10% of the \copylib.

Jimmy

William M. Klein

2005-03-07, 8:55 pm

Actually, you don't need to put the "*" in column 7 and the ">" in column 8.

If you start a line with "*>" anywhere after column 6, it will work.

You don't talk about the "/" for page eject - but I don't see that in very
common usage anymore. The '02 Standard allows fixed and free format to have a
statement.

You also don't talk about debugging lines. In the '02 Standard, both fixed and
free format support[color=darkred]

--
Bill Klein
wmklein <at> ix.netcom.com
"Russell" <rws0203nospam@comcast.net> wrote in message
news:Xns96127CE1F176Arws0203comcastnet@2
16.196.97.131...[color=darkred]
> LX-i <lxi0007@netscape.net> wrote in news:afdb7$422c4e68$45491f85$25530
> @KNOLOGY.NET:
>
> two
>
> Another option would be use a format in cpy files that works
> with both free and normal. Eg, columns 01-06 are blank (only), never go
> past column 72, comments are marked by an "*" in column 07, and a ">" in
> column 08. You are not allowed to put "-" in column 07 (or anything else
> but spaces as well).
>
> Start paragraph names in column 08, all else in column 12.
>
> Have I missed anything?
>
> This should work whether or not you are in "free" mode or not.

Richard

2005-03-07, 8:55 pm

> 1) Actually, you don't need to put the "*" in column 7 and the ">" in
column 8.

> 2) If you start a line with "*>" anywhere after column 6, it will
work.

2) is compiler dependent. 1) should work with _any_ compiler, even
'74.

Russell

2005-03-07, 8:55 pm

I don't know how widespread the "*>" comment is. A "*>" in
col 7 would work on any compiler. However, since we are talking
about compilers that support freeform, I suppose that the
distinction is pointless.

I have no idea what to do about "/" and "D", other than
do not use.

"William M. Klein" <wmklein@nospam.netcom.com> wrote in
news:IP1Xd.4391408$f47.787549@news.easynews.com:

> Actually, you don't need to put the "*" in column 7 and the ">" in
> column 8.
>
> If you start a line with "*>" anywhere after column 6, it will work.
>
> You don't talk about the "/" for page eject - but I don't see that in
> very common usage anymore. The '02 Standard allows fixed and free
> format to have a
> statement.
>
> You also don't talk about debugging lines. In the '02 Standard, both
> fixed and free format support
>

> LX-i <lxi0007@netscape.net> wrote in news:afdb7$422c4e68$45491f85$25530
> @KNOLOGY.NET:
>
> two
>
> Another option would be use a format in cpy files that works
> with both free and normal. Eg, columns 01-06 are blank (only), never
go
> past column 72, comments are marked by an "*" in column 07, and a ">"
in
> column 08. You are not allowed to put "-" in column 07 (or anything
else
> but spaces as well).
>
> Start paragraph names in column 08, all else in column 12.
>
> Have I missed anything?
>
> This should work whether or not you are in "free" mode or not.

LX-i

2005-03-07, 8:55 pm

William M. Klein wrote:
> Actually, you don't need to put the "*" in column 7 and the ">" in column 8.

You do if you want it to work with fixed format as well... :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

William M. Klein

2005-03-07, 8:55 pm

You don't if you have a compiler with the '02 Standard's fixed form reference
format.

If your compiler accepts *> as an inline indicator - then it (probably) accepts
it in any format.

A line like:

*> This is a comment

will be treated as a comment no matter where the "*" is.

If you have a compiler that doesn't accept "*>" as inline comment indicator for
fixed format, then I doubt that it accepts it for free format either.

--
Bill Klein
wmklein <at> ix.netcom.com
"LX-i" <lxi0007@netscape.net> wrote in message
news:4642e$422cc399$45491f85$7817@KNOLOG
Y.NET...
> William M. Klein wrote:
>
> You do if you want it to work with fixed format as well... :)
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
> ~ / \ / ~ Live from Montgomery, AL! ~
> ~ / \/ o ~ ~
> ~ / /\ - | ~ daniel@thebelowdomain ~
> ~ _____ / \ | ~ http://www.djs-consulting.com ~
> ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
> ~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
> ~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
> ~ h---- r+++ z++++ ~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Chuck Stevens

2005-03-07, 8:55 pm

"LX-i" <lxi0007@netscape.net> wrote in message
news:4642e$422cc399$45491f85$7817@KNOLOG
Y.NET...
> William M. Klein wrote:
column 8.[color=darkred]
>
> You do if you want it to work with fixed format as well... :)

Well, I think Bill already established that the context was one in which the
*compiler* would support either one.

In that environment, I think it's probable that any implementation would
have allowed "*>"
as a floating indicator anywhere (including after nonblank data in the line)
in both fixed-form and free-form reference formats according to the 2002
standard.

The Unisys MCP COBOL85 implementation, in an extension to (its) COBOL
standard, certainly allows "*>" as a floating comment indicator, and I
seriously doubt that that compiler's unique among ANSI-85 implementations in
doing so.

-Chuck Stevens

Russell

2005-03-07, 8:55 pm

"Chuck Stevens" <charles.stevens@unisys.com> wrote in
news:d0igvb$1pek$1@si05.rsvl.unisys.com:

>
> "LX-i" <lxi0007@netscape.net> wrote in message
> news:4642e$422cc399$45491f85$7817@KNOLOG
Y.NET...

Now that I think about it a little more, you don't have to
put the "*>" in col 7 & 8, but you do need to avoid putting it
any farther to the left (if you want the same copybook to work whether or
not you are in freeform mode or not).

I am not sure that I want to bet what just ANY compiler would do
with a "*>" in cols 02-06. Or col 01 for that matter (Microfocus
excluded).

> column 8.
>
> Well, I think Bill already established that the context was one in
> which the *compiler* would support either one.
>
> In that environment, I think it's probable that any implementation
> would have allowed "*>"
> as a floating indicator anywhere (including after nonblank data in the
> line) in both fixed-form and free-form reference formats according to
> the 2002 standard.
>
> The Unisys MCP COBOL85 implementation, in an extension to (its) COBOL
> standard, certainly allows "*>" as a floating comment indicator, and I
> seriously doubt that that compiler's unique among ANSI-85
> implementations in doing so.
>
> -Chuck Stevens
>
>
>

apknight@gmail.com

2005-03-08, 3:55 am

apknight@gmail.com

2005-03-08, 3:55 am

If I has not setting "SOURCE FORMAT" the copy texts, was occured error?
( only setting original source marked "free" )

Chuck Stevens

2005-03-08, 3:55 pm

Xref: newsfeed-west.nntpserver.com comp.lang.cobol:109463

"Russell" <rws0203nospam@comcast.net> wrote in message
news:Xns9612C4FA9F1E0rws0203comcastnet@2
16.196.97.131...

> I am not sure that I want to bet what just ANY compiler would do
> with a "*>" in cols 02-06. Or col 01 for that matter (Microfocus
> excluded).

If the ">" ended up in Column 7 I'd expect some sort of complaint from the
compiler (for fixed-form reference format in '02 COBOL, and unconditionally
for earlier standards). ">" is not a character the compiler recognizes as
meaningful in Column 7.

If the ">" is in Column 6 or before, I think compilers are pretty much
obligated to accept -- and ignore -- what's there.

ANSI X3.23-1974 says (page 1-106) that a sequence number , consisting of six
digits in the sequence area *may* be used to label a source program line but
does not (as far as I can tell) impose an obligation on either the user or
the implementor to enforce the limitation.

ANSI X3.23-1985 goes further. On page IV-42 it states that any characters
at all may appear in that area, and further states that the content is
whatever the *USER* (not the *IMPLEMENTOR*) wants it to be.

What I would *not* expect in fixed-form reference format (of any vintage) is
for "*>" appearing anywhere in Columns 1-6 to be treated as introducing a
comment.
..
-Chuck Stevens

James J. Gavan

2005-03-08, 3:55 pm

Chuck Stevens wrote:
> "Russell" <rws0203nospam@comcast.net> wrote in message
> news:Xns9612C4FA9F1E0rws0203comcastnet@2
16.196.97.131...
>
>

>
> What I would *not* expect in fixed-form reference format (of any vintage) is
> for "*>" appearing anywhere in Columns 1-6 to be treated as introducing a
> comment.
> .

As Ronnie Regan would have said with his pleasing smile, "There you go
again....".

Micro Focus - Fixed format, starting in column 1

*>---------------------CustomerEdit.cbl ---------------

* You can ignore this line

*> You can ignore this one too

> (No text as I have here - but accepts the Column 1 value)

> This it didn't accept, (i.e. my text) - looking for a paragraph

Just compiled to prove it. Don't like # 4, and I can see it rejecting #
5, but the first three are OK by me.

Jimmy

Russell

2005-03-08, 8:55 pm

"Chuck Stevens" <charles.stevens@unisys.com> wrote in
news:d0koc2$8ns$1@si05.rsvl.unisys.com:

>
> "Russell" <rws0203nospam@comcast.net> wrote in message
> news:Xns9612C4FA9F1E0rws0203comcastnet@2
16.196.97.131...
>
>
> If the ">" ended up in Column 7 I'd expect some sort of complaint from
> the compiler (for fixed-form reference format in '02 COBOL, and
> unconditionally for earlier standards). ">" is not a character the
> compiler recognizes as meaningful in Column 7.
>
> If the ">" is in Column 6 or before, I think compilers are pretty much
> obligated to accept -- and ignore -- what's there.
>
> ANSI X3.23-1974 says (page 1-106) that a sequence number , consisting
> of six digits in the sequence area *may* be used to label a source
> program line but does not (as far as I can tell) impose an obligation
> on either the user or the implementor to enforce the limitation.
>
> ANSI X3.23-1985 goes further. On page IV-42 it states that any
> characters at all may appear in that area, and further states that the
> content is whatever the *USER* (not the *IMPLEMENTOR*) wants it to be.
>
> What I would *not* expect in fixed-form reference format (of any
> vintage) is for "*>" appearing anywhere in Columns 1-6 to be treated
> as introducing a comment.
> .
> -Chuck Stevens
>
>

To recap (this newreader trims my replys, and I haven't figured out
how to stop it yet), this was in reference to code that would be useable
on BOTH fixed format and freeform format, without bothering to tell the
compiler which you are using. This could be useful in copy files.

Assume that you have a compiler that allows free form.

1. cols 1-6 blanks only.
2. comments start with "*>" in col 7 or greater.
3. Paragraph headers start in col 8.
4. Source starts in col 12.
5. Nothing goes past col 72.
6. No continued lines ("-" in col 7).
7. No debug lines.
8. No page eject or whatever.

If you limit the comments to start in col 7, than
the copy file could be used in a 68 compiler, although
avoiding continued lines would be bothersome without
concatenation (&).

Chuck Stevens

2005-03-08, 8:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:B%mXd.611889$8l.224991@pd7tw1no...
> Chuck Stevens wrote:

vintage) is[color=darkred]
a[color=darkred]
>
> As Ronnie Regan would have said with his pleasing smile, "There you go
> again....".

Why the patronizing stance, Jimmy?

ANSI '85 COBOL does not have a fixed-form reference format in which the
indicator area can be anywhere but Column 7 or in which the program-text
area can begin anywhere other than Column 8. Columns 1-6 can be any
characters the user wishes and have no impact on what the compiler does with
the remainder of the source image.

Micro Focus can call what you describe "fixed format COBOL" until the cows
come home, but as you describe it, the format is, and ought to be flagged
as, a Micro Focus extension to standard COBOL. It is compliant with neither
the current standard (fixed-form or free-form reference formats) nor the
prior one (which has only one reference format).

Note that I have no problem with "*>" appearing anywhere in Columns 1-6 of
'85-compliant source. What's in Columns 8-margin R should be compiled
unless something in Column 7 tells it otherwise, and the compiler should
*not* be deciding whether to compile the program-text area of standard COBOL
based on what's in columns 1-6. According to the standard, as I see it
that's *user documentation* territory and it *better not* have any impact on
the compilation of the line!

-Chuck Stevens

James J. Gavan

2005-03-08, 8:55 pm

Chuck Stevens wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:B%mXd.611889$8l.224991@pd7tw1no...
>
>
>
>
> vintage) is
>
>
> a
>
>
>
> Why the patronizing stance, Jimmy?

Oh that human communication problem ! Should I have put a very nice
pleasant smilie to convey the meaning.

Regardless of whether or not the cow's come home, I find it useful to
use, particularly Example 1 - although to be truthful, most of the time
I do that starting in Column 8. The odd occasions when I do start
in Column 1 are where I might have a couple of paragraphs as a notation
what the program sequence is, (i.e. I don't want to restrict the
comments to Columns 8 through 72), - not your normal run-of-the-mill
programs - but as a reminder to me down the road, should I need to go
back and take a look and reflect on what the program was designed to do.

In my context, I'm not thinking of OO support classes but rather the
mechanics of an OO Business Control Class - quick example - converting
RM data files to M/F - naturally the new output whether or not COBOL
files or SQL Tables differs, because of enhancing the application. Sure
enough some new info required is not available in the RM data - that
necessitates flagging both missing, cross-reference and input validity
errors. I may have done it incorrectly, but my approach is a three-stage
process. Best way to handle that was Decision Tables to cover all
eventualities - hence start notation at Column 1.

As to whether or not it is flagged by M/F - I have no idea. Might be. I
care neither for flagging nor setting directives - just take the default
version of the compiler, whatever it happens to be. (Subsequently,
should I have a problem I can say to M/F "Can't do this. What's the
solution ? I'm using N/E 3.1 with Default settings").

I still LIKE YOU :-) - but you are very passionate about the Standards.
Ummm .... I wont reflect any more on the word 'Standards'.

Jimmy

>
> ANSI '85 COBOL does not have a fixed-form reference format in which the
> indicator area can be anywhere but Column 7 or in which the program-text
> area can begin anywhere other than Column 8. Columns 1-6 can be any
> characters the user wishes and have no impact on what the compiler does with
> the remainder of the source image.
>
> Micro Focus can call what you describe "fixed format COBOL" until the cows
> come home, but as you describe it, the format is, and ought to be flagged
> as, a Micro Focus extension to standard COBOL. It is compliant with neither
> the current standard (fixed-form or free-form reference formats) nor the
> prior one (which has only one reference format).
>
> Note that I have no problem with "*>" appearing anywhere in Columns 1-6 of
> '85-compliant source. What's in Columns 8-margin R should be compiled
> unless something in Column 7 tells it otherwise, and the compiler should
> *not* be deciding whether to compile the program-text area of standard COBOL
> based on what's in columns 1-6. According to the standard, as I see it
> that's *user documentation* territory and it *better not* have any impact on
> the compilation of the line!
>
> -Chuck Stevens
>
>

William M. Klein

2005-03-08, 8:55 pm

Chuck and Jimmy,
From the N/E V4 LRM

"(MF) If the first character position of the sequence number field contains an
asterisk, or any non-printing control character (less than the character SPACE
in the ASCII collating sequence), then the line is treated as comment, and is
not output to the listing file or device. This facility allows an output listing
file to be used as a source file to a subsequent compile. This support is
sensitive to the MFCOMMENT Compiler directive."

I think it is pretty clearly documented as an MF extension. I haven't tried it
with either
FLAGSTD
or
FLAG(ANSI)

but I think MF is pretty good (better than some vendors - like Fujitsu) in
flagging those things that they DO document as an extension.

P.S. Historically (as I recall) this was a "useful" extension in that it
allowed MF compiler listings (with page headers and other "info") to be "fed
back" into the compiler itself (as "valid" source code).

--
Bill Klein
wmklein <at> ix.netcom.com
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:x0qXd.612754$Xk.272775@pd7tw3no...[color=darkred]
> Chuck Stevens wrote:
>
> Oh that human communication problem ! Should I have put a very nice pleasant
> smilie to convey the meaning.
>
> Regardless of whether or not the cow's come home, I find it useful to use,
> particularly Example 1 - although to be truthful, most of the time I do that
> starting in Column 8. The odd occasions when I do start
> in Column 1 are where I might have a couple of paragraphs as a notation what
> the program sequence is, (i.e. I don't want to restrict the comments to
> Columns 8 through 72), - not your normal run-of-the-mill programs - but as a
> reminder to me down the road, should I need to go back and take a look and
> reflect on what the program was designed to do.
>
> In my context, I'm not thinking of OO support classes but rather the mechanics
> of an OO Business Control Class - quick example - converting RM data files to
> M/F - naturally the new output whether or not COBOL files or SQL Tables
> differs, because of enhancing the application. Sure enough some new info
> required is not available in the RM data - that necessitates flagging both
> missing, cross-reference and input validity errors. I may have done it
> incorrectly, but my approach is a three-stage process. Best way to handle that
> was Decision Tables to cover all eventualities - hence start notation at
> Column 1.
>
> As to whether or not it is flagged by M/F - I have no idea. Might be. I care
> neither for flagging nor setting directives - just take the default version of
> the compiler, whatever it happens to be. (Subsequently, should I have a
> problem I can say to M/F "Can't do this. What's the solution ? I'm using N/E
> 3.1 with Default settings").
>
> I still LIKE YOU :-) - but you are very passionate about the Standards. Ummm
> .... I wont reflect any more on the word 'Standards'.
>
> Jimmy
>

William M. Klein

2005-03-08, 8:55 pm

Russell,
The rules that you describe are useful for source code that needs to be
"valid" for BOTH an '85 (fixed form reference format only) and an '02 Compiler
(either fixed form or free form reference format).

If, on the other hand, one is creating source code that will be valid for fixed
or free form reference format BUT only for compilers that support the '02
Standard's source code (not extensions to the '85 Standard), then the follow
rules work:

1) leave columns 1-7 blank (spaces)
2) do not have source code past the R-margin (defined by this implementer) for
fixed form reference format
3) Use *> to indicate comment lines (starting in column 7 or later)
4) Use >>D to indicate debugging lines
5) Use >>PAGE directive (instead of "/" in column 7)

Source code following the above rules WILL compile successfully in either fixed
or free form reference format - for any compiler supporting the '02 Standards
rules (whether they do or don't support the rest of that Standard)

--
Bill Klein
wmklein <at> ix.netcom.com
"Russell" <rws0203nospam@comcast.net> wrote in message
news:Xns961397A135501rws0203comcastnet@2
16.196.97.131...
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in
> news:d0koc2$8ns$1@si05.rsvl.unisys.com:
>
>
> To recap (this newreader trims my replys, and I haven't figured out
> how to stop it yet), this was in reference to code that would be useable
> on BOTH fixed format and freeform format, without bothering to tell the
> compiler which you are using. This could be useful in copy files.
>
> Assume that you have a compiler that allows free form.
>
> 1. cols 1-6 blanks only.
> 2. comments start with "*>" in col 7 or greater.
> 3. Paragraph headers start in col 8.
> 4. Source starts in col 12.
> 5. Nothing goes past col 72.
> 6. No continued lines ("-" in col 7).
> 7. No debug lines.
> 8. No page eject or whatever.
>
> If you limit the comments to start in col 7, than
> the copy file could be used in a 68 compiler, although
> avoiding continued lines would be bothersome without
> concatenation (&).

Russell

2005-03-09, 3:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in
news:mfqXd.4498720$f47.804910@news.easynews.com:

> Russell,
> The rules that you describe are useful for source code that needs to
> be
> "valid" for BOTH an '85 (fixed form reference format only) and an '02
> Compiler (either fixed form or free form reference format).
>
> If, on the other hand, one is creating source code that will be valid
> for fixed or free form reference format BUT only for compilers that
> support the '02 Standard's source code (not extensions to the '85
> Standard), then the follow rules work:
>
> 1) leave columns 1-7 blank (spaces)
> 2) do not have source code past the R-margin (defined by this
> implementer) for fixed form reference format
> 3) Use *> to indicate comment lines (starting in column 7 or later)
> 4) Use >>D to indicate debugging lines
> 5) Use >>PAGE directive (instead of "/" in column 7)
>
> Source code following the above rules WILL compile successfully in
> either fixed or free form reference format - for any compiler
> supporting the '02 Standards rules (whether they do or don't support
> the rest of that Standard)
>

It always helps to ask someone that knows what they are talking
about. I wonder if anyone actually needs to have this level of
compatibility between radically different compilers.

The reason that I thought of this would be someone that wants to
start using free form cobol in a large system. It would be quite some
time before you get around to converting ALL of the programs to freeform,
and until you do, the copys are going to need to useable in both fixed
and free form.

The solution that puts a compiler directive at the top of each copy
setting fixed format, and another directive at the end setting free form
is obviously not going to work for the programs that have not been
converted to freeform yet.

And who wants TWO sets of copys.

I suppose that you could use conditional compiles ($IF) and a
constant to handle this problem, assuming that your compiler has this
capability. I have done that sort of thing to try and add an additional
working storage copy to multiple programs without editing them, when a
change to a commonly used procedure copy requires the new copy file.

William M. Klein

2005-03-09, 3:55 am

The '02 Standard also makes portable (when/if implemented) conditional
compilation - see

and
[color=darkred]

similar (but not quite identical to) the Micro Focus $IF type statements

(compile-time constants/variables are also slightly different between the '02
Standard and MF)

***

There definitely WAS a design goal in the '02 Standard that one SHOULD be able
to create source code that would compile in both fixed and free form reference
format. What there was SLIGHTLY less attention to was copy code that would
compile in the '02 Standard and the '85 Standard compilers. (Certainly a subset
will - but when it gets to debugging lines and page ejects, the compatibility
is ONLY for fixed form - which is - of course - the DEFAULT in the '02 Standard)

P.S. Debugging lines are made OBSOLETE in the '02 Standard - and "should" be
removed in the '09 Standard <G>. OTOH, conditional compilation should do all
that they can do - and more.

--
Bill Klein
wmklein <at> ix.netcom.com
"Russell" <rws0203nospam@comcast.net> wrote in message
news:Xns9614859EB4A3rws0203comcastnet@21
6.196.97.131...[color=darkred]
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in
> news:mfqXd.4498720$f47.804910@news.easynews.com:
>
>
> It always helps to ask someone that knows what they are talking
> about. I wonder if anyone actually needs to have this level of
> compatibility between radically different compilers.
>
> The reason that I thought of this would be someone that wants to
> start using free form cobol in a large system. It would be quite some
> time before you get around to converting ALL of the programs to freeform,
> and until you do, the copys are going to need to useable in both fixed
> and free form.
>
> The solution that puts a compiler directive at the top of each copy
> setting fixed format, and another directive at the end setting free form
> is obviously not going to work for the programs that have not been
> converted to freeform yet.
>
> And who wants TWO sets of copys.
>
> I suppose that you could use conditional compiles ($IF) and a
> constant to handle this problem, assuming that your compiler has this
> capability. I have done that sort of thing to try and add an additional
> working storage copy to multiple programs without editing them, when a
> change to a commonly used procedure copy requires the new copy file.

Chuck Stevens

2005-03-09, 3:55 pm

"Russell" <rws0203nospam@comcast.net> wrote in message
news:Xns9614859EB4A3rws0203comcastnet@21
6.196.97.131...
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in
> news:mfqXd.4498720$f47.804910@news.easynews.com:
>
>
> It always helps to ask someone that knows what they are talking
> about. I wonder if anyone actually needs to have this level of
> compatibility between radically different compilers.
>
> The reason that I thought of this would be someone that wants to
> start using free form cobol in a large system. It would be quite some
> time before you get around to converting ALL of the programs to freeform,
> and until you do, the copys are going to need to useable in both fixed
> and free form.
>
> The solution that puts a compiler directive at the top of each copy
> setting fixed format, and another directive at the end setting free form
> is obviously not going to work for the programs that have not been
> converted to freeform yet.
>
> And who wants TWO sets of copys.
>
> I suppose that you could use conditional compiles ($IF) and a
> constant to handle this problem, assuming that your compiler has this
> capability. I have done that sort of thing to try and add an additional
> working storage copy to multiple programs without editing them, when a
> change to a commonly used procedure copy requires the new copy file.

Russel, I think the standard covers this.

The default reference format for library text is the format that was in
effect for the COPY statement. A SOURCE FORMAT directive that is the first
line of library text can be in either fixed form or free form. And if a
SOURCE FORMAT directive is in library text, it is in effect until either
another SOURCE FORMAT directive is encountered *in the library text*, or the
end of the library text is reached. (ISO/IEC 1989:2002 page 57, 7.2.18.2,
SOURCE FORMAT directive, general rules.) .

-Chuck Stevens

Richard

2005-03-10, 8:55 am

Chuck Stevens

2005-03-10, 8:55 pm

Russell

2005-03-11, 3:55 pm

William M. Klein

2005-03-11, 3:55 pm

Chuck Stevens

2005-03-12, 3:55 am

James J. Gavan

2005-03-13, 3:55 pm

Sponsored Links