Re: Re[2]: fake out system

Why not  just  get a good  tool that will manage  this Vs.
 compound the Y2K  and mashed RPG  code sets?

It is not  going to get any better !!!

Glenn

At 09:00 AM 9/28/98 -0600, you wrote:
>
>     Yes, it's trouble. In my experience, shortcuts rarely ever save 
>     time in the long run. However, sometimes the only choices we have 
>     are the ones that let us do the quick fix now and leave the rest 
>     until later. Part of the additional confusion here comes from 
>     converting from RPGII to RPGIII as part of another project (Y2K). 
>     
>     Eric
>
>
>______________________________ Reply Separator
_________________________________
>Subject: Re: fake out system  
>Author:  <MIDRANGE-L@midrange.com > at INET_WACO
>Date:    9/26/98 11:33 AM
>
>
>Seems to  me that you are adding   a bit more confusion to an already 
>problematical mission. What   is the   suggested  method to keep  these 
>temporary  fixes documented so they are  used   properly and considered  as 
>future development and changes  occur?
>     
>Sounds  like trouble?
>     
>     
>Glenn
>_____________________________________________
>Glenn Ericson,            Phoenix Consulting                        
>P O Box 701164          East Elmhurst NY 11370-3164 USA
     
> 
>Phone 718 898 9805         Fax 718 446 1150 
>AS/400 & Year 2000- - Solutions Specialists
> c 1998 copyright,  all rights reserved
>____________________________________________
>     
>     
>______________________________ Reply Separator _________ 
>At 01:52 PM 9/24/98 -0600, you wrote:
>>
>>     1. Create DDS for replacement file, make sure field begin/end 
>>     positions match your pgm described record layout. Pad blank fields 
>>     as necessary. Add your new date field to the end of the new record. 
>>     2. Rename old file. 
>>     3. Create new file.  
>>     4. CPFY old new FMTOPT(*NOCHK) 
>>     
>>     The upside: programs that don't use the date probably won't need to 
>>     be changed at all. No recompiling required there. Modify programs 
>>     that use the datefld to use the external defs. 
>>     
>>     Downside: this could get REALLY confusing until all programs are 
>>     converted to using external defs. This won't work at all if you use 
>>     COPYFILE to maintain the files. Whenever you'd do the COPYFILE, 
>>     DELETE, RENAME , you'd end up without ext defs. 
>>     
>>     There's lots of gotchas in here. I'm sure I don't remember very 
>>     many of them. For one, you might need to create your file w/ 
>>     LVLCHK(*NO). Also, I'm not sure if the record format name needs to 
>>     be the same as your file name. If it's a keyed file, do the key 
>>     field names need to be K00001? I'm not sure.... 
>>     
>>     I know that you can make this scenario work. I've done it before. 
>>     It's just been too many years/margaritas since I figured it out.. 
>>     
>>     hth
>>     eric.delong@pmsi-services.com
>>
>>
>>____________ Reply Separator_________________
>>Subject: fake out system 
>>Author:  <MIDRANGE-L@midrange.com > at INET_WACO 
>>Date:    9/24/98 11:23 AM
>>
>>
>>I have run into a small problem on a system that I have to Y2k 
>>convert...
>>     
>>The system has many program described files, BUT, the one file that 
>>requires
>>adding a new date format ccyymmdd doesn't have any more 
>>space.....soooooo
>>     
>>I have thought about somthing along these lines: 
>>     
>>1. create external specs for file with DDS adding new date field 
>>2. create a logical with an exact layout of internal described file less 
>>new field
>>3. rename external described file to some other name 
>>4. rename logical to original internal described name 
>>     
>>I'll still have to modify any program that uses dates but a lot of them 
>>don't
>>really use the date,,, so that cuts out a LOT of conversion time..... 
>>     
>>As time permits, I'll go back and fix all programs to use new external 
>>description....
>>     
>>Is there some downside to doing the conversion this way ?????? 
>>+---
>     
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com. 
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. 
>| Questions should be directed to the list owner/operator:
david@midrange.com 
>+---
>     
>
>
>+---
>| This is the Midrange System Mailing List!
>| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
>| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
>| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
>| Questions should be directed to the list owner/operator: david@midrange.com
>+---
>


Glenn
___________________________________________________
Glenn Ericson,          Phoenix Consulting                      
P O Box 701164   East Elmhurst NY 11370-3164 USA                            
Phone 718 898 9805       Fax 718 446 1150
AS/400 & Year 2000- - Solutions Specialists
 © 1998 copyright,  all rights reserved
____________________________________________________


 
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---