Starting with 8.12 package name length limit is 8 characters

Thought I would post this in case it bit someone else:

I have a certain naming convention for packages that used 9 characters and I increment the package name by 1.

Example:

BDVOCU001
BDVOCU002


I got an interesting error in jde.log after a package build:

Package or Mobile Package 'BDVOCF00_M' already exists. Please change the name of the package 'BDVOCF00'.



From MetaLink3:

"The Package Assembly application will generate a red error if you enter a package name over 8 characters, but it will accept it up to 10 characters. The reason it was changed to allow only eight characters is because of the mobile packages. When you build a mobile package, it appends the packagename with _M, e.g. if your package is named DVF092908 (9 characters) it would attempt to change it to DVF092908_M (11 characters). The PKGNAME DD item only has a length of 10 characters, so the 11 character name would be invalid. If you're not using mobile packages and aren't bothered by the red error that pops up, then it's probably OK to enter in 10 character package names."


E1: PKG: Package Name Length Limit (Doc ID 664661.1)
https://metalink3.oracle.com/od/faces/secure/km/DocumentDisplay.jspx?id=664661.1&h=Y

wow - what a crock. someone had their head up their arse. why don't they change the length of the DD field for the mobile packages, morons....

Very typical, though: it had happened before and surely would happen again. They did the same to BSVW names not so long ago.

And worse, I have seen in many places the server names treated as NID's. And that's on top of NID's frequently copied into "char[10] / JCHAR[10]" variables along the way. Just establish a policy of never exceeding 6 characters for anything and you will be right ;-)

Lovely! I guess they figure no one would ever want to use a meaningful naming convention! I guess I'm goiing to have to start naming my Full packages with a single alpha character, and with my updates, just appending a numeric to it, that way, in the next release when the limit the number of characters EVEN MORE, I will be ok....

The standard package naming convention doesn't even work anymore. Wow.

[ QUOTE ]
The standard package naming convention doesn't even work anymore. Wow.

[/ QUOTE ]

And they did such an admirable job of communicating such an important change.

It doesn't even give one a proper error.

What are they thinking?

Silly boy, what made you assume that anyone was thinking?

Why break with tradition after all this time?

Hi.

I always disliked the standard package naming convention.

We name our packages like these

Full => AANNN where AA = Environment (DV, PY, PD), and NNN = sequential beginning at 001

Updates => AANNNNNN where the first AANNN = Full base, and NNN = Update Number

so

our first Full for PY = PY001 and then we made updates PY001001, PY001002, PY001003, etc

then next full for PY = PY002

and updates PY002001, PY002002, etc

I never liked to get non sortable names ;-)

the standard naming convention wastes too much letters in the non meaningful part of the name.

that's my 2c

Greetings

[ QUOTE ]
Hi.

I always disliked the standard package naming convention.

We name our packages like these

Full => AANNN where AA = Environment (DV, PY, PD), and NNN = sequential beginning at 001....

[/ QUOTE ]

Hola Carlos,

We use something similiar. Our naming conventions is:

AA1111F - like this, DV051809F. The fist two letters are the pathcode. Then the Month, Date, Year. Finally an F for a full or a U for an update package.

- Gregg

Hola Greg ;-)

[ QUOTE ]

Hola Carlos,

We use something similiar. Our naming conventions is:

AA1111F - like this, DV051809F. The fist two letters are the pathcode. Then the Month, Date, Year. Finally an F for a full or a U for an update package.



[/ QUOTE ]

Well, we are a small company, and don't have a regular schedule for updates or fulls, and sometimes we create updates everyday (when heavy develop happens), and we creates full s when we have too much updates or when we are making major changes (big esus, or any important system change)

so we opted for a naming convention not tied to dates.

just one note, I will change your naming convention to DV090518F (Env, year, month, day, type), so it is sortable ;-)

when I have to generate output and need filenames containiig dates I always use year in four digits, month, day like basename_20090518.csv thus I can sort the result by filename and they are sorted by date also (the ones of the same basename, ofcourse)



but it's only a suggestion ;-) fell free to keep with your package naming :-D



Best Regards

[ QUOTE ]

just one note, I will change your naming convention to DV090518F (Env, year, month, day, type), so it is sortable ;-)

[/ QUOTE ]

But it is now 1 character too long.

I've always argued AGAINST having dates in package names - never really seen the reason why people do that (you can put the date in the description if you REALLY want) - and you can't really see what update goes with what full in that way.

I used the modified "DV7333FA00" as a full package, followed by "DV7333FA01" to 99 as updates - and "DV7333FB00" being the following full package.

Of course, with the latest changes, package names should be the following :

DV812A00 - ie, pathcode followed by Series (letter) followed by two numbers - 00 indicating a full package, 01 through 99 being update packages.

That way, the package will sort correctly, will identify the pathcode AND what update goes with what full - and you can store up to 26 series (A through Z) before you have to re-use. Thats still a long time in most high-quantity development environments.

Just my 2c

I agree with Jon - I have never seen a reason to encode the date in the package name. When one displays packages the description field is right there below it, put the date in there. I disagree with Jon's putting the E1 version in the package name. If you don't know what version you are working on, getting it from a package name is not your best bet.

A naming convention should place as much information in the characters without placing any un-necessary information in it.

My naming convention:

Character 1 - Build for Client, Server, or Both
C, S, B

Character 2-3 - Path Code
DV, PY, PD

Character 4-5 - Build Reason
OC (Object Change), TS (Test), EU (ESU), TR (Tools Release)

Character 6 - Package Type
F (Full), U (Update)

Character 7-8 - Serial Number
0-9, 0-9

The description field - Date (mm/dd/yy) OMW Project Name Builders Initials (xyz)
Examples:

BPYOCU02
04/20/09 HRCSOVers jls

BPDTRF02
05/12/09 8.98.1.0 TR Update jls


Some Tools Releases will not install the specs databases unless the package name starts with the pathcode. This started somewhere in 8.97 and was fixed in 8.98.



My naming convention is the only correct one, all bow before my genius.




[ QUOTE ]
[ QUOTE ]

just one note, I will change your naming convention to DV090518F (Env, year, month, day, type), so it is sortable ;-)

[/ QUOTE ]

But it is now 1 character too long.

I've always argued AGAINST having dates in package names - never really seen the reason why people do that (you can put the date in the description if you REALLY want) - and you can't really see what update goes with what full in that way.

I used the modified "DV7333FA00" as a full package, followed by "DV7333FA01" to 99 as updates - and "DV7333FB00" being the following full package.

Of course, with the latest changes, package names should be the following :

DV812A00 - ie, pathcode followed by Series (letter) followed by two numbers - 00 indicating a full package, 01 through 99 being update packages.

That way, the package will sort correctly, will identify the pathcode AND what update goes with what full - and you can store up to 26 series (A through Z) before you have to re-use. Thats still a long time in most high-quantity development environments.

Just my 2c

[/ QUOTE ]

Hi.

the date change was only a suggestion to make it sortable ;-)

As I said before my naming is AANNN for Fulls and AANNNNNN for updates where AA is the Env (PD, PY, DV), and NNN is the sequence, and in updates the first AANNN is the base full, and the last NNN is the update number

ie: PD001 (first full PD Environment), PD001002 (Second update of first full on PD) so we can use 999 fulls and 999 updates for each full (we have reached 123 updates in one PD full ;-))

Also our descriptions vary, for a Full package is the full reason (change in DDL, change in database, ESU, or November 2008 Full)

In our upgrades we only indicate the ID of the case or cases (from our ticketing system), that originates the update (like TRID 1745, 1789, 1792) so if anyone need to check what's the cause of this update, can enter our ticketing system and review all the process from the request to the development.

This way is easy for us to check if any workstation has missed one package reading the package.inf, or build a script that install a full and all its updates to a workstation, as our package names are well sortable and identifiable.

currently we are on DV018019, PY017027 and PD012029, and we build

DV018 in February 2009
PY017 and PD012 in October 2008

we are reaching the need of a new set of fulls ;-)

Also our naming convention for Object Development is similar, ie:

Applications

PCCSYNNN
P = application
CC = Customer code we use 55 for JD edwards developed during Implementation, 56 for our custom development
SY = system code development, if is a sales development = 42, Inventory = 41, etc
NNN = Development numnber (up to 999 developments for system area)

The report is the same but with and R instead of P

And the process options

TPCCSYNNN => T for process option and the application it goes for and for a report TRCCSYNNN

A table FCCSYNNN
A View VCCSYNNN or VCCSYSYNNN (view join form 2 diff systems)

a Bussiness Function NCCSYNNN or BCCSYNNN

we like the use of a base name (meaning) + sequence number (series) to have a consistent naming without losing capacity for growing.

I still use a Date based pak name
Had to adapt and replaced 6 digit date to 5 digit (same two for year but Julian for day
I.e. DF09001 for a Full D(V) pak assembled on Jan 1st.
CU09005A cor a C(RP) U(pdate) pak assembled on Jan 5th; A stands for first update pack on that day - I can always have another one built later as CU09005B

Why use a date in the package name?

A package = a snapshot of central objects as replicated objects at a point in time.

So long as they appear in order it doesn't matter much, I've been using:

PC YYMMDD F or U (WXYZ) for years.

One variation is PC YMMDD U1 2 etc

PC YMMDD F or U (WXYZ) would fit with 8 chars.

I can't remember the last time I did a client only, or server only package. Under 8.12 there isn't a lot of difference anyway.

We use the following:

DV90923FA

DV = pathcode
9 = year
09 = month
23 = day
F = full
A = first build for that date

So if we were doing update packages, it'd be:

DV90923UA
DV90923UB
etc...if we had more than one per day...