|
Thanks, Scott. This is what I'll wind up doing. I guess the reason this is more difficult than it should be is because this is a vendors product that somewhat still supports it. If I change this program dramatically they won't understand it and not be able to do some of the maintenance they may have to do. I have to program down to them. Regards, Jim Langston Scott Klement wrote: > > Jim, > > If you're just looking for a quick hack to get this thing working, > replace the READ/WRITE/EXFMT to the record format in question with > subroutines/subprocedures. > > Make the subroutines use MOVE or EVAL to make the data go into each > of the data structures. > > It shouldn't take more than a few minutes (using this method) to make it > so that you only have one field to deal with in the input specs. > > The process of converting it to be externally defined is a bit more > difficult, but hardly an "extensive change". Either use the same field > names in the ext def as you have in the program, or use SEU's ability > to find/replace a string to change all the field names in the program. > > (and, of course, replace any EXCPT's with UPDATE/WRITE... but you did > that when you created your subroutines) > > Or maybe I don't understand? Because this doesn't seem like it's that big > of a deal to me... > > On Thu, 19 Apr 2001, Jim Langston wrote: > > > Yes, the people who wrote this package develop, pretty much, spaghetti code. > > > > And yes, eventually, all the files in the program will be externally > > defined, but this is one of many projects I have on my list and it needs to > > get done as soon as possible, yesterday if possible <grin>. > > > > And, yes again, those were file keys in question for the data structures. > > > > That's what I was afraid of, having to modify this program extensively > > to get it to work with externally described files. > > > > Regards, > > > > Jim Langston > > > > VWilliamson@glazers.com wrote: > > > > > > I've never heard of program describing a subfile. From an old S36 person > > > whose converted several hundred to RPGIII and RPGIV. How would you fill > > > it or readc the subfile records? > > > > > > Is there some reason why you don't want to externally define the disk >files > > > also? At least 2 of the data structures look like definitions for file > > > keys. These you can replace with KLIST if externally defined. Otherwise, > > > I think you have no choice except to eval or move to these extra > > > definitions when you read each subfile record. > > > > > > I guess it all depends if you're working with spaghetti code or not. > > > > > > Valene M. Williamson > > > IBM Certified Specialist > > > vwilliamson@glazers.com > > > 972-448-8018 > > > > > > +--- > > > | This is the RPG/400 Mailing List! > > > | To submit a new message, send your mail to RPG400-L@midrange.com. > > > | To subscribe to this list send email to RPG400-L-SUB@midrange.com. > > > | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. > > > | Questions should be directed to the list owner/operator: >david@midrange.com > > > +--- > > +--- > > | This is the RPG/400 Mailing List! > > | To submit a new message, send your mail to RPG400-L@midrange.com. > > | To subscribe to this list send email to RPG400-L-SUB@midrange.com. > > | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner/operator: >david@midrange.com > > +--- > > > > +--- > | This is the RPG/400 Mailing List! > | To submit a new message, send your mail to RPG400-L@midrange.com. > | To subscribe to this list send email to RPG400-L-SUB@midrange.com. > | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
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.