Logical with a different record format from physical, POLL

[DeadManWalks]

Hi,

This is related to the post;
http://www.code400.com/forum/showthread.php?t=5774

I am just curious to see how many people make a logical file with a different record format then the physical.

[bryce4president]

Re: Logical with a different record format from physical, POLL

I have only written maybe 1 or 2 logicals since I've stared a little over15 months ago. The way I was taught was that you just used the same record format. Thanks for the new idea, I hadn't realized they should or even could be different.

[GLS400]

Re: Logical with a different record format from physical, POLL

Hi DMW:

I don't consider myself "old school" but I don't see any advantage to using a new record format with the "rename format" available

GLS

[Mercury]

Re: Logical with a different record format from physical, POLL

What the heck is it worth using a different record format name ? Except maybe when you want an excerpt of the original format in order to avoid the implicit RPG move's in your programs ?

[tomholden]

Re: Logical with a different record format from physical, POLL

it's not old school...it's common sense. use the same record format as the physical. the ONLY reason i can even think of justifying a different record format would be for join LFs and multi-format LFs. which I never have and never will create! they just plain suck...if you need more than one file...write the frigging F specs already. the ONLY thing multiformat LFs should be used for IMO is for maybe EDI formats. as far as join LFs...geez can't you write a CHAIN, SETxx, READE statement...anyway that's my rant for now LOL

[Chipper]

Re: Logical with a different record format from physical, POLL

I tried using a different record name at some point in the past but couldn't figure out how to do it. I'd be curious to see how some of the other regulars weigh in regarding the pros and cons of one way over the other.

[DeadManWalks]

Re: Logical with a different record format from physical, POLL

Multi-format logical files are great for EDI.

Here is what some data looks like when using a multiformat logical'

18             06241632181453001ZZ 16897                                
18             06241632181453002CR 4502897520                           
18             06241632181453001BT POWERTRACK                           
18             06241632181453001311 MOORE LANE                          
18             06241632181453001XXXXXXXXXLLE                  XX99999   
18             06241632181453101000001                                  
18             06241632181453101001INLAND TRANSPORTATION                                                              
18             06241632181453101001000000000  000000999900000000000000000000         450     INLAND TRANSPORTATION    
18             06241632181453102000002                                                                                
18             06241632181453102002FUEL SURCHARGE                                                                     
18             06241632181453102002000000000  000000099900000000000000000000         FUE     FUEL SURCHARGE           
18             062416321814530001997200G 000000000  000000179000000000000000000000   00000000 0000320        00000000 

I would never use a different format in a logical. I was just curious since I say someone post in a different thread the suggestion.

[arrow483]

Re: Logical with a different record format from physical, POLL

Normally, I use the same. But a use for a different format name is when you don't want all the fields. For example, you have an application that needs the employee name from the payroll master file, but you don't want the user to have access to any other fields. So you build a LF over the payroll master, with a different record format name and only the 2 fields desired. Then the user (like a foreman) can have read access allowed for this LF, and no access to the PF.

[Billw]

Re: Logical with a different record format from physical, POLL

Under what situation would they have access to the logical directly using SQL/Query? This kind of data would be accessed ONLY through an inquiry program and then under security options.

So it would not make any difference what fields you have defined in the logical.

$0.02 CDN

[SG_FTL]

Re: Logical with a different record format from physical, POLL

as far as join LFs...geez can't you write a CHAIN, SETxx, READE statement...

i recently discovered join LF's to be enormusly useful when i had to add an extra display column on a subfile screen with multiple fields.

here's the scenario.
The subfile displays data from file A. A new column is to be added to the subfile display. the new column to be added needs to go from file B. You could say, use file B in the F specs and chain the record pick the field and populate the new column. But in my case, file B's field value would depend on a value coming from another box....not the same iseries box. It would have taken extra routines to do that as opposed to simply reading a jpoin logical file(which practically doesnt need any coding). all the select criteria and omit criteria are definedd in the join LF , so the records come filtered , and doesnt have to be programmed in your RPG.

If I have to add a new field in file A and then display the subfile, fine, it would work. But the implications were , I would have to change 50 other programs that use File A with the old format. so now i use a join logical file for both file A and file B, add a new field in the subfile display format, read the join logical file when the subfile loads.....and voila!! i have my new column added on the screen without having to change million other programs, because i 'd have changed a PF layout.



anyhoo....i havent used multiformat logical files up until now....so i dont know any benefits/harm about that.

[GLS400]

Re: Logical with a different record format from physical, POLL

Hey Arrow:

I think you "can" use the same format name in your
scenario. Just select the fields / keys you want users to have access to.

GLS

[arrow483]

Re: Logical with a different record format from physical, POLL

Under what situation would they have access to the logical directly using SQL/Query? This kind of data would be accessed ONLY through an inquiry program and then under security options.

Ideally, that would be true. And there are other ways (such as adopted authority, etc). When possible, I prefer the database keep them out. Today there are lots of PC tools that run SQL queries, (Excel comes to mind, also VB, etc). Actually, I find rare use for this "field level security" - this was just to illustrate a use for different RF names.

[arrow483]

Re: Logical with a different record format from physical, POLL

I think you "can" use the same format name in your
scenario. Just select the fields / keys you want users to have access to.

I know that didn't use to be possible. I have to admit, I haven't tried to use the same format name with different formats for a very long time. I usually don't do the selection in the LF, in most cases I am using SQL views (that pretty much ignore format names).

[littlepd]

Re: Logical with a different record format from physical, POLL

We use logicals with different record format names whenever the actual record format is different. For example, the General Ledger Details file has over 50 logicals build over it, some for journal entries, some for A/P, etc. The G/L Detail file has all the different data for each different type in the same file. But you sometimes don't need or want fields that have to do with job cost when you're dealing with A/P or A/R. The logicals don't have those fields (they're treated like SQL views). In these case, the record format names are different because they have to be.

However, if the number and order of the fields in the logical exactly matches that of the physical, there is no reason (IMHO) to use a different record format name between the two.

[littlepd]

Re: Logical with a different record format from physical, POLL

The main package that I've been working on for the last few years uses a technique whereby a description or name field from a physical file is used as the first (or only) key field in a logical file. Now, you might think that this would pose a problem when users are allowed to enter mixed-case data into these fields. How do you sort them alphabetically when users may not have used the same input standards, as far as case goes, when entering data?

This is how it's done:

     A**   Division Name file (Logical File of DIVSN Physical) DIVSN01 TE01   
     A*                                                                       
     A          R DVNMREC                   PFILE(DIVSN)                      
     A            DIV#                                                        
     A            DIVDSC                                                      
     A            DVCAPS             I      RENAME(DIVDSC)                    
     A                                      TRNTBL(QSYSTRNTBL)                
     A          K DVCAPS

Here you have the DDS for the logical file DIVSN01. There is an extra field added to the format (DVCAPS) which uses two DDS keywords: RENAME() & TRNTBL().

The RENAME keyword is used to specify that the field DVCAPS is the same as the physical fiel field DIVDSC, just with a different name. This is done because the field DIVDSC has already been defined in the logical file. When you want to different fields in your logical to refer to the same field in your physical, use RENAME.

The TRNTBL keyword is where the magic happens! This keyword is used to specify the name of a translation table that the system uses when passing data back and forth between the physical file and your program. The system-provided table QSYSTRNTBL translates the letters a through z to uppercase.

So, keying the logical by the DVCAPS field (1) converts all the descriptions to uppercase, then (2) sorts them alphabetically. Your program reads the logical records by this key, but uses the DIVDSC field from the logical file to display the mixed-case version of the description on the screen.

In this case, because I have included the extra field DVCAPS in my logical file record format, I can't use the same record format name as in the phsyical file.