Re: More than 80 columns

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