Shawn Gordon wrote:
>
> this solution appeared to require more actual code work that fixing the
> programs and expanding the data.  If expanding the data was the problem,
> both Adager and DBGeneral had options to do this, and my experience was
> that it worked great.  I guess the limiting factor was getting the clients
> to run the data transformation process.  the new HP date intrinsics at
> least made it less painful to do date math and such with these types of
> dates.
>
> Tracy Pierce <[log in to unmask]> on 01/05/2000 12:08:46 PM
>
> Please respond to Tracy Pierce <[log in to unmask]>
>
>  To:      [log in to unmask]
>
>  cc:      (bcc: Shawn Gordon/IS/FHM/FHS)
>
>  Subject: Re: Y2K and Sorted YYMMDD Image paths!
>
> I vote for *KLUDGE*.  I wonder if they did this because disk is too
> expensive to expand to 8-digit dates?
>
> Tracy Pierce,
> Golden Gate Bridge

It's because it's too expensive to modify the source modules for the
extra data lengths. There's no such thing as a Copy Module in Basic/V so
each source module must have the change made individually.

Add to this that Growthpower clusters all it's Datasets into Strings
first, Short NonIEEE Reals next, and Long NonIEEE Next. Unsorted dates
are stored in Short Reals which can't hold 8 digits. Sorted Dates are
stored in 6 characters. Since Strings occur first, all fields are
anywhere from one to four long single string variables. Order Headers
are stored in W5$,W6$,W8$,W5[*],X5[*] where W5$ is something around 225
bytes. Order Date might be in something like W5$[22;6] or something.
Expand that to 8 and you must change each and every W5$ reference beyond
this up by two bytes. In every source module.

Worse, some modules are close to the 32k Code Segment limit. Just adding
a few characters to data fields could cause Compile Failure. That would
force the module to be split into two or functionality removed to make
space. (This is why Order Entry is something like 40 source modules).