RE: Standards issue - Comments please.

When IBM was designing RPG IV, they left open column 46, which I used to
refer to the "Just in case Cozzi was right" column.
I had asked IBM to allow the output specs to be coded as "Starting
positions" rather than "ending positions", but that wasn't backwards
compatible with RPGII and RPG III so they left it in as is.  But they
added an unused or "reserved" column 46 just in case the RPG programmers
demanded that they be allowed to specify that output fields specifed as
"start" rather than "end" positions.  Today, I'd rather see a keyword
the Output heading lines that says something like "ENDPOS" and
"STARTPOS".

The makeshift choice today to allow start positions is really to use
relative positioning. Something like this:

     OQPRINT    E            Heading        1
     O                                           +2 'Field Name'
     O                                           +2 'Type'
     O                                           +4 'Length'
     O                                           +1 'Dec'
     O                                           +1 'Text'

Where each field is +n positions way from the previous field's ending
position. This was in RPGIII as well. But is certainly not as clear or
easy to calculate as true starting positions.

I've never caught the externally described printer file badwagon, but I
think they're pretty cool. Today, I just avoid using them a wish IBM
would enhance the output specs to include support for underlining, bold,
color, barcode, etc, etc. etc.

Bob

-----Original Message-----
From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]
On Behalf Of Fisher, Don
Sent: Friday, January 03, 2003 3:01 PM
To: 'rpg400-l@midrange.com'
Subject: RE: Standards issue - Comments please.


O-specs are simpler to code and easier to maintain?  Huh?

Let's see now, with a printer file, I can use RLU or CODE/400 to see the
report layout and actually see the results of my changes.  With O-specs
I must perform many calculations of field length to determine the
beginning and end point of a field to ensure no overlap occurs.  I must
also constantly refer back to other O-specs to ensure the columns line
up with the headings.

Of course, all of the above doesn't matter much if you have detailed
specifications that include a report layout and character position
ruler.

O-specs do have a couple of advantages over the printer file.  First,
you can use array fields with a variable subscript such as ARR,A as
fields in the specifications.  They also provide automatic line,
heading, and total printing tied to the logic cycle (NOTE: I HAVE
OFFERED NO OPINION ON THE
CYCLE) and to whether the overflow line has been reached.

Personally, I think a report program being self-contained and having
fewer members to check out are rather specious arguments.  Do these
people also use internally defined display files and not the DSPF
objects?

In the end, it may come down to personal preference, but if you want to
establish a shop standard, you might as well go with printer files.
They offer more features such as advanced function printing, bar codes,
IPDS functions, and other stuff that cannot be done with O-specs.  That
is, of course, just my opinion.

Hope that helps.

Donald R. Fisher, III
Project Manager
The Roomstore Furniture Company
(804) 784-7600 extension 2124
DFisher@roomstoreeast.com

<clip>
(The group that favors O-spec)
"O-specs are simpler to code and easier to maintain"
"Report programs are self contained"
"Fewer members to check out"

(Now the PRTF group)
"PRTF is simpler to code and easier to maintain"
"Separation of presentation attributes from report logic makes report
layout changes easier" "PRTF can support advanced features such as
barcoding, font control, embedded images/graphics, etc."

<clip>
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@midrange.com To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.