BSVW Object name length in 812 (limited to 8)

[johndanter]

Hello!

I've been tasked with a rather large task of replicating code already written the US
I'm in the UK on 8.12, our other instance on 8.0

As I'm copying their solution I've noticed that some of their BSVWs are upto 9 chars long.
Theyve amended B9800020 to allow BSVWs etc to be 10 long.

Look in the code, you'll see the simple IF on line 145.

So I asked my ERP manager, for ease of replication (as this stuff uses a lot of C++ to create strings that ref these objects to call several UNIX scripts)...

Can I please change our B9800020 to allow me to a letter for letter replication of the US code.

No he said! It's dangerous bla bla bla.

So I pointed out that the US have done it and it's fine, plus it will save me a headache in not having to cross ref their object names with ours

Is there ANY danger to me changing that BSFN just like the US have done?

Sorry for the long winded question

John

 

[BOster]

Its only dangerous if you are on an AS400 is my understanding.
We are not on an AS400 so here is the snippet from my B9800020 with the annoying piece of code commented out:

if ( (jdeStricmp( (const JCHAR *)((JCHAR *)(lpDS->szFunction)), (const JCHAR *)((JCHAR *)(FUNCTIONCODE_APPLICATION))) == 0 ) ||
(jdeStricmp( (const JCHAR *)((JCHAR *)(lpDS->szFunction)), (const JCHAR *)((JCHAR *)(FUNCTIONCODE_TABLE))) == 0 ) ||
(jdeStricmp( (const JCHAR *)((JCHAR *)(lpDS->szFunction)), (const JCHAR *)((JCHAR *)(FUNCTIONCODE_BUSINESSFUNCTION))) == 0 ) ||
(jdeStricmp( (const JCHAR *)((JCHAR *)(lpDS->szFunction)), (const JCHAR *)((JCHAR *)(FUNCTIONCODE_CONSOLIDATEDBSFN))) == 0 ) )/* ||
*----------------------------------------------------------------------
* Acme Mod Begin
*----------------------------------------------------------------------*
(jdeStricmp( (const JCHAR *)((JCHAR *)(lpDS->szFunction)), (const JCHAR *)((JCHAR *)(FUNCTIONCODE_BUSINESSVIEW))) == 0 ))
*----------------------------------------------------------------------
* Acme Mod End
*----------------------------------------------------------------------*/

 

[DBohner-(db)]

List,

Technically:
- An iSeries does not have issues with BSVWs that are 10 Characters long. A BSVW is nothing more than an SQL Definition - the BSVW's Object Name is never actually planted as any sort of named object on the system.
- Now that the iSeries is a Relational Database (ok, now that it uses real DB architecture), the ten character naming convention for tables names doesn't really exist. Though, I've never really tried to see how long a Table_Name I could create through SQL
- Prior to 8.something - Developers could create BSVW with names up to 10 characters. I'm working with an 8.0 to 9.0 project, currently - and we have boomeranged several 10 Character BSVWs into 9.0, and they are working. I'm not sure what tools release or upgrade took away that ability
- In 9.0, we cannot create a BSVW that is longer than 8 characters. I feel this is STUPID - as, wouldn't it be nice to have a table F5511111 with BSVWs named V5511111A, V5511111B & V5511111C?
- I know that Oracle can 'permit' 10 Character BSVW Names, I recall one of the sessions at Collaborate - where the presenter commented that they got a hotfix from Oracle to allow the change (otherwise - there would have been years of rework). Apparently, they were unaware that Boomerang could deposit a Naming Convention that breaks the rules and still works

I don't know what Oracle's Hotfix was - I'm sure it is very similar to what Boster is presenting.

Pennies-more!

(db)

 

[BOster]

Well, if you upgrade from a prior version all of your existing BVs with names longer than 8 chars come over just fine the way they are, you just can't create NEW BVs w/ 10 char names. After talking w/ a consultant that was working on our upgrade about the mod he said that he has seen that mod on numerous installs. I went ahead and made the mod almost a year ago and nothing seems to have gone wrong.

I mean zombie kernels spiked by 8000% but thats a CNC issue right (joking of course...)?

 

[craig_welton]

If I remember right, on the AS/400 the source and header files used to live in the library structure, not the IFS. I belive this was in XE and before. Because JDE appends the BV in front of business view header file, the name was longer that 10 characters. So the server package build would crash when trying to create the member.

Someone else may remember more accurately ...

 

[johndanter]

Thanks for the replies lads

It's exactly what I thought (as DSTRs can be upto 10 and its fine)

Anyway, cut a long story short, I've been told to do what I'm told

My opinion doesn't matter as it's not my system

Any change to OMW is a no no here. And they're just a tad too scared to let me comment out the C++

Hey ho

Thanks anyway but it's falling on deaf ears here.

John

PS: I will post up another 8.0 to 8.12 C++ question in a moment

 

[JMR]

[ QUOTE ]
- An iSeries does not have issues with BSVWs that are 10 Characters long. A BSVW is nothing more than an SQL Definition - the BSVW's Object Name is never actually planted as any sort of named object on the system.

[/ QUOTE ]

Daniel,
While that statement is mostly true, it is not always true which is why E1 must keep the restriction.

If you have a bsvw checked-out and you 'Create a type definition', an include file is generated and plopped into the \include folder with a 'B' prefixed to the BSVW name (V550001A becomes BV550001A.h). When you do a check-in, the new .h file will be moved along with the object specs. This file WILL be created as an iSeries object just like any other .h file.

Obviously, this is only a concern when a BSVW will be used in any business functions (c or NER), but a concern nonetheless.

My issue is why the name has been restricted to 8 characters when it appears only 1 character (leading 'B') is added to the object name?

Moral of the story: if you are not on an iSeries and you are absolutely positive you never will be, then go ahead and remove the restriction (see Brian's post above for the code to do so).

 

[DBohner-(db)]

Thanks Jer,

I knew that someone would define the errors in my thoughts... Being that not an issue with DataBase, it is an issue with Object Naming Limitations.

Thus, they should allow us to have At Least 9 Character BSVW Names. Being that; "B" + 9-Characters = a 10 Character Object Name.

I did a quick scan of our DV900 Include folder - Oracle appears to be lying do us. There are quite a few BV*.h headers that extend to 10 characters. Many of those are in modules that are more recent than the 'law of 8' has been in existence.

Thanks for helping me/us understand the issue.

Knowing is half the battler - and I've been learned by one of the best.

(db)