× 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.



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

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.