|
You just run in the 36 environment. Didn't say I would want to, only that it was still just as good as it ever was (which may not saying much). Don't mean to be busting your chops on this. The original point was not than internal was better than external or vice versa, just that it makes sense to externalize print files for the very same reasons that it made sense to externalize screen files and database files. Just much more modular and easier to maintain. I don't about you, but I was overjoyed to get rid of I & O specs. Why stop halfway? Get rid of the remaining O-specs used by the printfiles. Keeping them, to me anyway, is like getting rid of all your left-hand indicators but tenatiously hanging on to the right-hand ones (Why, 'cause we've always done it that way?). BTW, the external printfile can be used by many programs if you just make it generic. I've used this approach before, at a previous shop, just by doing a printfile override at the beginning of the program which sets all the attributes of the "generic" printfile to be whatever that particular program needs it to be. In fact, I had five generics available, which allowed the program to select and customize and print to up to five different print files at a time. Each printfile had 88 lines, containing one large field on each line. The print programs simply loaded up a MODS with 88 occurrances and called a generic print program that would print out one page at a time. Very much like working with one screen at a time except it was all loaded up dynamically. The pages being printed could be done sequentially or intermixed or however you wanted them to be. The overrides controlled everything and as you moved from one print program to another, you just reset the overrides for however many printfiles you needed. Many of my screen programs use the same concept. Just 24 lines of 79 character fields that are loaded up dynamically inside the program to print anything you want. Admittedly, it doesn't work too well for input fields, b ut it's great for output only, which is what the reports are and a great many screens. ILE has made all this so much easier, once you get a service program of procedures set up and working. A little be tedious to initially build, but then you can use 'em everywhere. Anyway, whatever floats your boat..... ----- Original Message ----- From: "Bale, Dan" <DBale@lear.com> To: <RPG400-L@midrange.com> Sent: Wednesday, April 12, 2000 10:17 AM Subject: RE: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What's the difference!!!) > I must be suffering from severe brain fade. I can barely remember the > torture of coding screens on the S/34/36, but believe that $SFGR (?) specs > were required to do _any_ screen I/O. No??? You could do screens in RPGII > using straight I-specs and O-specs with no other external screen object? In > S/34, S/36, or AS/400? > > I've done "subfiles" on the S/36 using arrays. But I don't remember > implementing them without using $SFGR specs. > > Please enlighten me. > > - Dan Bale > > > -----Original Message----- > > From: Nelson C. Smith [SMTP:ncsmith@gate.net] > > Sent: Tuesday, April 11, 2000 9:04 PM > > To: RPG400-L@midrange.com > > Subject: Re: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What's > > the difference!!!) > > > > Certainly. RPGII works just as well as it ever did. Wrote subfiles on a > > S/34 for years. Only difference was we had to roll our own using arrays. > > In some ways, it was easier. Do I define my screens internally now? Of > > course not. External is a greatly appreciated improvement. Ditto for > > print > > files. Ditto for disk files. > > > > ----- Original Message ----- > > From: "Bale, Dan" <DBale@lear.com> > > To: <RPG400-L@midrange.com> > > Sent: Tuesday, April 11, 2000 11:25 AM > > Subject: RE: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What's the > > difference!!!) > > > > > > > I strongly disagree. _Can_ you define screens internally? Other than > > DSPLY > > > opcode? Subfiles? > > > > > > Totally different ballgame > > > > > > > -----Original Message----- > > > > From: Nelson C. Smith [SMTP:ncsmith@gate.net] > > > > Sent: Monday, April 10, 2000 10:16 PM > > > > To: RPG400-L@midrange.com > > > > Subject: Re: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What's > > > > the difference!!!) > > > > > > > > Every argument made for internal print files fits equally well for > > > > internal > > > > screen files. Do you define your screens internally? > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Bale, Dan" <DBale@lear.com> > > > > To: <RPG400-L@midrange.com> > > > > Sent: Monday, April 10, 2000 10:35 AM > > > > Subject: external *PRTF (was: RE: 'ILE RPG' or 'RPG IV' . What's the > > > > difference!!!) > > > > > > > > > > > > > Really don't mean to start a holy war here <g>, but... IMNSHO: > > > > > > > > > > External printer files - BLEAAHHH! If it's used in only one > > program, > > > > which > > > > > is the case for 99.95% of all printer files I've ever come across, > > then > > > > keep > > > > > it in the RPG source! > > > > > > > > > > Granted, had IBM's braindead RLU been something closer to what RDA > > (by > > > > > BugBusters???) is, then I might have formed a different opinion ten > > > > years > > > > > ago. Then again, since RDA allows you to choose between creating > > > > printer > > > > > DDS specs or RPG O-specs, who knows? There's really not a whole lot > > you > > > > can > > > > > do in DDS that can't be done in RPG O-specs for _most_ printer > > output. > > > > > > > > > > Honestly, though, it really isn't an "ease of design / development" > > > > issue > > > > > with me. For me, it's an "ease of maintenance" issue, since I do > > much > > > > more > > > > > maintenance than new development. > > > > > Internal: One source member. External: Two source members. > > > > > Internal: No confusing where the printer file source is; it's right > > > > there. > > > > > External: Ever been in a JBA shop? 'nuf said. > > > > > Internal: One edit session, one compile. External: Two edit > > sessions, > > > > two > > > > > compiles. > > > > > Internal: When RPG compile error occurs, you just need to look for > > > > errors > > > > in > > > > > the RPG source. External: When RPG compile error occurs, you need > > to > > > > check > > > > > the RPG compile listing, oops - not there, now go check the printer > > file > > > > > DDS, make corrections, recompile DDS, recompile RPG. > > > > > > > > > > All that said, I always follow the shop standards. I can do printer > > > > specs > > > > > either way. > > > > > > > > > > Jon, please indicate why you think "it is just better and safer to > > > > describe > > > > > these things externally." > > > > > > > > > > - Dan Bale > > > > > > > > > > > -----Original Message----- > > > > > > From: Jon.Paris@halinfo.it [SMTP:Jon.Paris@halinfo.it] > > > > > > Sent: Saturday, April 08, 2000 9:08 AM > > > > > > To: RPG400-L@midrange.com > > > > > > Subject: Re: 'ILE RPG' or 'RPG IV' . What's the difference!!! > > > > > > > > > > > > PS. I don't think printer files have _anything_ to do with using > > them > > > > in > > > > > > multiple places any more that display files do - it is just better > > and > > > > > > safer to > > > > > > describe these things externally. > +--- > | 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.