|
There is almost always more than one way to do anything in programming. Holy wars have gotten started on which ways are better (cycle or no cycle, logicals or no logicals, data queues or data areas, etc...) The fact is, to be truely effective you are going to need to know about all of them. You don't need to really know all of them, but need to know how each works. Such as I knew what data queues were, but never had a call to use them, and now I do. Thanks to the fine people on this list, I was given samples of how to use 'em using the APIs. So, although I did not know how to use them, I knew how they worked. One thing you should do is read up on every OP code in RPG. It is not that difficult to just go through the op code list and read about each one. Also, do the same with the CL books. What each command is. Even though you many never use one, you'll know it exists. When I first started in RPG I had to get up quickly, and one of the things I did was take the CL manuals and start reading cover to cover. I quickly found that I did not have to read every word, but went over each command. I did the same with the RPG programming manuals, playing closest attention, like I said, to the command lists. Also, look at other's code. And always understand, that just becuase that particular programmer did it one way, someone else may do the exact same thing totally different. Regards, Jim Langston "Cobb, Laura" wrote: > Just starting out, I don't want to form any bad habits or practices in my > code. So thank you for giving me the constructive insight on OVRDBF and > logical files. After reading the replies READE is obviously a better > choice. I wish there was a book out there with opinions and insight on the > better ways to approach the coding of a project or program. Or something to > the effect of "Only code it using this approach if ......." My biggest > fear is coding myself into a corner so to speak and then having to do a huge > overhaul of a bunch of programs because initially I didn't choose the best > way to go about things. > Well enough said. > > Thanks Again, > LAC > > -----Original Message----- > From: Jim Langston [mailto:jlangston@conexfreight.com] > Sent: Thursday, June 08, 2000 4:20 PM > To: RPG400-L@midrange.com > Subject: Re: F Specs on an OVRDBF > > Denis is right, but on the note of what do your F-Specs need > to look like? > > Your F-Specs do not really need to change at all. The logic > in your program > may need to change if it is a different type of key, but if > it is the same key read > in both files, your RPG program will have no idea if it's > reading a physical file > or a logical file. They both look exactly the same to the > RPG program, and you > treat them exactly the same way. That is the magic of > OVRDBF and logicals. > > Regards, > > Jim Langston > > Denis Robitaille wrote: > > > You can do it with OVRDBF but I would not. But first, let > supposed that you do go the OVRDBF way. > > > > Lets say that your logical are named P701L1 and P701L2. In > your F spec use P701L1 and in your CL > > you use one of the 2 following override depending on which > vendor you want to access: > > OVRDBF (P701L1) to (P701L1) > > or > > OVRDBF (P701L1) to (P701L2) > > > > That will work. > > > > But then again, I think that this is a bad way to solve > this problem. What if you add another vendor, you will have to had a new > logical and you will have to modify the CL. And what if you change a vendor > number ... > > > > A better approach would be: > > > > - create one logical file (lets call it P701L1) with the > key made of the vendor number and the product number next. > > - then you pass as a parameter to your RPG program the > vendor number that you want to work with. > > - In the RPG program, use the READE opcode instead of the > READ opcode (look up the manual, you will understand the difference) to > extract record from the P701L1 file > > > > This way, you will need just one logical file regardless > of the number of vendor and this way, any change in the number of vendor or > their id will have no impact on the CL or RPG program > > > > Hope this help. > > > > Denis Robitaille > > Directeur services techniques > > Cascades Inc > > 819 363 5187 > > fax 819 363 5177 > > > > >>> LCobb@PapaGinos.com 06/08/00 02:25pm >>> > > > > Salutations, > > > > I have a product master file (P701). I had to write the > online maintenance > > in such a way that when the DP clerk selects product > maintenance they are > > prompted as to which vendor they wish to do maintenance > on. So only those > > products with that particular vendor code are accessible > through > > maintenance. I created two logicals utilizing the select. > One for each > > vendor. > > I know I can do it with BLDQRYSLT, but I prefer to try to > utilize OVRDBF in > > my CLP. I have only been programming for a year. I am > self taught and I > > want to get a better grasp on this OVRDBF. My boss allows > me to learn > > everything I can, to try new approaches whenever possible, > and get exposure > > on all that RPG, CL, and SQL has to offer. (RPGIV is > coming soon). That is > > why I am choosing OVRDBF (if it is possible). > > My question is (because my boss is on vacation) what do my > Fspecs need to > > look like? I have looked in all the manuals and > infoseeker but I can't find > > this info. > > I am thinking my CL should be: > > OVRDBF (PFILE) TO (VENDOR CODE SPECIFIC LFILE) > > > > Should my Fspecs contain only the PFILE (update) or do I > need the > > LFILE's(input) in there also? > > > > Am I even close with this? Am I wrong in thinking that it > can be done this > > way? > > > > Thank you in advance for any info or insight you can shed > on this matter. > > > > LAC > > +--- > > | 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 > +--- +--- | 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.
midrange.com
