DOH...you're right....memory failing time for an upgrade....anyone have
some to spare lying around? must fit in a ancient chipset...
Thanks,
Tommy Holden
From:
CRPence <CRPbottle@xxxxxxxxx>
To:
rpg400-l@xxxxxxxxxxxx
Date:
04/22/2009 11:33 PM
Subject:
Re: More than 80 columns
Sent by:
rpg400-l-bounces@xxxxxxxxxxxx
Alan Campin wrote:
Tommy Holden wrote:
in v6.1 there is an option to lengthen the columns
available...now if i can just remember where it is lol
FWiW I think it was the RUNSQLSTM which was enhanced for longer
record lengths of its source, not creating RPG from its source.
Manual say 8 to 80. I don't believe they can ever extend it
because of the original developers decision to have 8 to 80 as
source and anything beyond the 80 character as comment.
If they had made the comment as a separate field then they could
have the source line any length you wanted and you could have
handled it but with the comment starting at 81 I cannot imagine
anyway to do it without screwing up other things.
Oh ye of little creativity ;-) The only limitation in making
that happen would be if the compiler were only allowed to infer
based on the maximum record length. That would not function [well]
because old sources with already longer than 80-byte records could
be problematic; e.g. positions 81-100 are used for comments.
The removal of the limitation can happen, to enable that change,
for any specific compile from source. One example: something like
an H-spec and\or a compiler option, could inform the compiler that
the full record length [fixed or stream] should be used as input.
If also on a SRCLEN() or SRCLINE() parameter, then with some special
values & single value(s) with perhaps two elements, that could
enable some invocation examples like: SRCLEN(*PUNCH), SRCLEN(8 80)
/* same as *PUNCH */, SRCLEN(*HSPEC) SRCLEN(8 100), SRCLEN(1 *END),
SRCLEN(*CR), SRCLEN(*CRLF)
Of course, if they had not done this terrible idea of multiple
members in a file in the first place they won't have had the
problem but hindsight is 20/20.
Not sure the relevance of multi-member to record length, other
than that the primary object called the database *FILE defines the
fixed record length for all members. Nor why source members are a
terrible idea. IMO there is nothing inherently wrong with the
source member for text [source code] storage. I believe the real
problem was that the concept of the punch card programming was
carried into the chosen replacement source container which was
externalized as members of a /source physical file/. Had they
realized then, that there was no reason to keep the legacy concept
of fixed-positions imposed by the punch, they could have simply gone
free-form at that time; i.e. there would have been no reason to keep
an 80-byte limit. But even having moved to the fixed-length record
source container, the free form with capability of larger text line
lengths would work fine [even if that implementation wastes space as
compared to stream data storage, but even that could be changed].
Regards, Chuck
midrange.com
