|
Bottom line - printer files do not have variable-length fields. Don't even try!First of all, it makes no sense to have them there, as one of the main reasons for varchars is to save space, and there is no true "space" involved with printer files.
If you must have a varchar in the physical file, you MUST move it to a printer file field of a different name. This is probably a preferred practice in general, although this can be debated (maybe more preferred with display files).
I must ask why you want a varchar in the physical file - especially since you have not specified an allocated length. In this case, with allocated length = 0, every read of the record requires 2 reads from disk - it is a performance issue here. This is because of the implementation of varchars on iSeries - data longer than allocated length is stored in a separate, auxiliary space. Other systems may handle this differently, iSeries does it using the fixed-length record format structure of physical files, so had to do this auxiliary thing.
Here is a quote from Midrange Guru in 2003:
To answer your first question, you first need to understand how varying-length fields are defined and stored on the iSeries. When you define a varying-length field, you specify a minimum allocated length and a maximum length. Varying-length fields are most useful for fields that contain values that vary greatly in their length. I have seen dramatic performance improvements on the iSeries when long fixed-length fields were converted to varying-length.A varying-length field is stored in one to three parts. The first part is a 2-byte length. The second part follows immediately after the 2-byte length and is present if a minimum allocated length is specified. The third part is also optional and is present if the length of a varying-length field's value is greater than the minimum allocated length. This third part is not part of the record and is stored in a separate area of the file. Accessing this separate storage area adds some additional overhead, so keep this in mind when defining varying-length fields, and use an allocated length that fits the majority of your field values if the length of those values is relatively consistent.
SQL Server and others know nothing of this allocated minimum - it's an iSeries-only thing - so the default of 0 is always used, with the possible performance issues attendant.
HTH Vern At 03:02 AM 3/6/2006, you wrote:
Hi, I checked again, if I try to print a varchar field using RLU, and compile the RPGLE, it gives error: "Varying Length input field is not defined internally as varying length" My Table is: Create Table Acc(Acode char(21), Aname Varchar(50)) My RPG Code is as under:- FACC IF E DISK RENAME(ACC:ACCN) FRPTRLU O E PRINTER /FREE READ ACCN; DOW NOT %EOF; WRITE DET; READ ACCN; ENDDO; *INLR=*ON; /END-FREE My RLU DDS is: A R DET A ACODE 21A O 1 A SPACEB(001) A ANAME 50A O +1 Do I have to put Varying Keyword in RLU or RPG ? Best Regards, Luqman "Vernon Hamberg" <vhamberg@xxxxxxxxxxx> wrote in message news:7.0.0.16.2.20060305174644.03863138@xxxxxxxxxxxxxx > Well, not a question of better. PRTFs and QMQRYs are completely > different animals. PRTFs give you more control over what you see in a > report. QMQRYs by themselves give you a default layout in columns. If > you want formatting, you need to couple a QMQRY with a QMFORM. QMQRYs > and QMFORMs together give you what QRYDFNs do by themselves - get the > data and present it on screen or in a report. > > You cannot use a QMQRY as you would a PRTF in RPG - it is not a file > that can be named in an F-spec. It is executed using the STRQMQRY > command, where you can optionally name the QMFORM used for > presentation. And this is a CL command, so it is not intended for use > in RPG - yes, you CAN use QCMDEXC, but that's not what it's for, for > the most part. > > As I posted, source record length is irrelevant - long constants and > captions, etc., get wrapped properly in the keywords columns. > > There has never been a point to VARCHARs in PRTFs. You handle them by > reading the physical file with the varchar in RPG, then writing out > to the PRTF after moving the data to a report field. You know this, I think. > > As to header/detail reports, it might be possible with QMQRYs - I've > never done it, and I use these things all the time. And promote them > all the time. Consider first that a QMQRY is a single SELECT > statement - essentially a single file in RPG terms. you'd need to use > a JOIN to get header and detail information together. No such thing > as reading the header file, then getting matching detail records. I'd > say regular RPG file processing is probably more efficient that > joining in a SELECT statement. Can't prove that, however. > > Now it is possible to use level breaks in a QMFORM. And you can have > break level text. You can have a header for each break, specify that > it does not start on a new page, and that column headings are not > repeated. You can put field references into this header. You can also > have footers, which is typically where subtotals go. And you can put > field references there, as well. So you could probably get a > header/detail report - might be very nice, in fact. There are some > limitations - e.g., the header/footer text in QMFORMs must all be in > pieces <= 55 long. But you can have LEFT, CENTER, & RIGHT on the same > lines, so this isn't so bad. > > If you use QMQRY/QMFORM you would not need the RPG at all, probably. > QMQRYs can have substitutions variables, so you can use a CMD front > end to a CL to get the values you want to put into the SELECT, then > start the QMQRY, and ba-da-bing, you're done. > > HTH - I know I might try this a little more myself. > Vern > > At 02:40 PM 3/5/2006, you wrote: > > >Which is more better for reporting in RPG, STRRLU or STRQM? > > > >I have noticed that STRRLU PRTF File does not support :- > > > >1. Source File > 92 > >2. Varchar Field > > > >Any suggestions please? > > > >Can I create a formatted report in STRQM, say, a Master/Detail Report. > > > >for example:- > > > >Master Record > >========== > > > >Name : Luqman Address: Room No. 27, Cantt Road,Karachi > >Tel : 1234567 E-Mail : myemail@xxxxxxxxx > > > >Detail Record > >========== > >Order Details of Luqman > >Item No. Quantity Rate Amount > >1 23 1 23.00 > >2 20 2 40.00 > > --- ------ > > Total: 43 63.00 > > --- ------ > > > >Best Regards, > > > >Luqman > > > > > > > > > >-- > >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > >To post a message email: MIDRANGE-L@xxxxxxxxxxxx > >To subscribe, unsubscribe, or change list options, > >visit: http://lists.midrange.com/mailman/listinfo/midrange-l > >or email: MIDRANGE-L-request@xxxxxxxxxxxx > >Before posting, please take a moment to review the archives > >at http://archive.midrange.com/midrange-l. > > -- > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > > -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
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
