Re: modernize problem with DDS logical

You shouldn't add the new fields to the existing logicals or the new
logical with the same name as the original physical.

For any RPG Program that needs the new fields, create a new logical with
the new fields. As long as it has the same key as an existing LF, there's
no additional overhead.

I wouldn't normally change the type of an existing field either. But if
the only change is zoned to pack, you should be able to redefine it in the
existing logicals. That will leave the record format ID of the existing
logicals unchanged.

Charles

On Mon, Dec 22, 2014 at 5:00 PM, Dale Janus <dalejanus@xxxxxxxxxxxxxxxxx>
wrote:

First off, I must apologize for to Chuck and everyone for my DDS
example. With the idea of making my message more compact, I forgot to
include the key spec at the bottom to match up to the UNIQUE keyword.

I think you should use the FOR COLUMN clause when you generate columns

with
names longer than six(6) characters, Something like:

CREATE TABLE MYLIB/MYFILE (
lONGFIELDNAME FOR COLUMN NAME06 CHAR( 32) NOT NULL WITH DEFAULT
)


HTH,

Luis

I was anticipating using the new file layout with rpg ile, so I foolishly
got carried away with longer FOR COLUMN names for the new fields. I
should have kept them at 6 characters.



First off, You can mix and match DDL & DDS. Views over PF and LFs over

Tables...

What you're saying doesn't make sense. Either the new fields are in the
logical or they are not. If they are not, the compiler wcn't and can't
see
them.

I use the same technique. If you do it right, you don't have recompile
anything. The Record Format Level ID should be the same from the original
to the new...on DSPFD, look here:

Record Format List
Record Format Level
Format Fields Length Identifier
MYFILER 114 541 2FED88D05AB32 <-- this ID should not
change

Charles

Based on what you are telling me, I need clarification on how to define
the logicals.

The original physical was called AROPEN. It had normal field definitions
and no key. It has been replaced with a new physical file called
AROPENSY. This new file was created in DDL with long column names, but
original 6 character System name for the original fields. The extra fields
added as part of the modernization have both long column names and System
names that are longer than 6 characters. A poor choice on my part.

The original AROPEN has 18 fields that look like this:
A R ARREC
A*
A ARCODE 1 COLHDG('DELETE' 'CODE')
A ARPRFX 2 COLHDG('OH,TX')
A ARMNTH 2 COLHDG('MONTH' 'NBR')
A ARSNBR 5S 0 COLHDG('INVOICE' 'NBR')
A EDTCDE(Z)
etc...

My original logicals looked like this and are named AROPENL1, AROPENL2,
AROPENL3, AROPENL4, each with a different key.
A UNIQUE
A R ARREC PFILE(AROPEN)
A K ARSNBR

No field names listed.


So here is what I changed.

I don't need my original file AROPEN. I do need all the logical files
AROPENL1, etc. As a test, I changed AROPEN to a LF, added the field names
(reference R code used) and it points to the correct data.

I added R for reference for the logicals:

0002.00 A UNIQUE
0003.00 0002 A R ARREC PFILE(AROPENSY)
0004.00 A*
0005.00 A ARCODE R
0006.00 A ARPRFX R
0007.00 A ARMNTH R
0008.00 A ARSNBR R
...
0026.00 0006 A K ARSNBR



The DDS compiles, and if I do a quick and dirty UPDTA AROPENL2, I can
acccess the record by putting valid data into ARSNBR .


However, this new logical AROPENL2 points to fields that went from decimal
to packed in new PF AROPENSY. The old program is getting no record found
on chain ARSNBR.

I will continue to play around with this, but thanks to everyone for
getting me going in the right direction.


---Dale







--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.