Object Alias

[JorgeJDE]

Hello,

I have a request that requires modifications to an interactive application, but I don't want to change the pristine object. If I remember correctly, there was a way in JDE to copy the application, make the changes to the copy and then setup some kind of "cross reference" that would allow the system to reference the program by its original name...?

For instance, the original program is P4310 and the copy is P554310, but throughout the system, whenever P4310 is called, it actually runs P554310. How can this be setup?

Would greatly appreciate any help here. Thanks.

JorgeJDE

E1 8.0/Rls 7334 SP23/AS400

 

[Scott Beebe]

Unless there is something new that I am not aware of, there isn't a way to set up a mapping to have calls to P4310 go to P554310. You would need to change every application and menu that refers to this application to call the new one.

Many times it is better to modify the pristine object.

 

[Remo Williams]

at several clients, we have copied pristine objects like p4310 and p4210 (and their proc option templates) to p55- (and t55-) objects, and then customised the p55-objects. then we slightly modified the pristine objects to basically, when called, link directly to their corresponding p55-copies (this involves a couple lines of code in certain events). this way, after an esu, the p55-copy remains untouched, and the pristine object will only need these few lines put back in.

 

[BOster]

[ QUOTE ]
after an esu, the p55-copy remains untouched, and the pristine object will only need these few lines put back in.

[/ QUOTE ]

IMO, another negative of the copy-and-mod approach. If you mod the pristine object, when an ESU comes out you have the option to retrofit your mods or retrofit the ESU. If you copy and mod, you basically have one option, retrofit the ESU to the copied object... that is if you remember that you copied the pristine object. A lot of times ESUs that SHOULD get retrofitted to a copied object don't because they are simply missed. You won't miss an ESU if you mod the pristine object since you will be forced to deal with it.

I know that the general school of thought is that it is better to copy-and-mod. I think this belief has more to do with "..thats the way we have always done it.." or "..thats what Oracle recomends.." than logically thinking it through. After over 8 years of JDE development including tons of mods to pristine objects as well as dealing with the headache of tons of copy-and-mods I have come to the conclusion that it is MUCH, MUCH better to mod the pristine object. There are always exceptions, but my first options is always to mod the pristine object.

 

[Larry_Jones]

I'm with Brian and Scott. Most times you should mod - not copy.

 

[Remo Williams]

yes, i prefer modding the original object as well (and have done so a lot of times as well, depending on the client situation). i was just mentioning an option. i'm aware of the drawbacks.

each option has its own drawbacks

 

[DBohner-(db)]

My general rules are:
Get the Terminology correct (my terminology):
- Pristine Objects are those that are in the PS Environment
- If you modify an object, consider it a Base or Production Object

Rules:
1 - Try not to modify any Base Objects
2 - Modifying an Object should be considered if it is an In-Line object (called by one or more other objects)
3 - If a Modification has to occur - Save the original as %59 or something (so you always have the Base Object for ESU References)

IMHO....

(db)

 

[DBohner-(db)]

Just a side-note to that Alias concept...

Like the others - I'm not aware of anything in E1 that would allow you to do such. In World (iSeries) - there is similar functionality, but it's been a long time since I honored the GreenScreen and I believe it was more mental than the original request.

Now... on the old Digital VAX/VMS and Alphas - YES, you could do just that... Whole E-911 systems are build using the Alias process (and, of course, a language called OddBall)...

More information, than I really should remember ....

(db)

 

[Chan Rana]

This more depends on the impact or degree of change on the Pristine object(and offcourse your company's policy). If its minimum or if you are able to keep your custom code seperate then its better to go for Pristine change.
The risk of changing Pristine is if most of your Pristine objects are modified then it becomes very tideous for developer to prove the bug is related to custom code or Pristine code.

Chan

 

[Remo Williams]

true. like is said: each option has its own drawbacks.

we are digressing though from the original question about the "cross reference" thing (not that i mind though

).

 

[Larry_Jones]

No no no Chan.

NEVER change code in the Pristine Path Code other than via ESU from Oracle.

You make your changes in DEV and promote from there.

Use Pristine environment (unmodified) to prove bug is Oracle's not customization (or vice versa).

 

[Chan Rana]

Larry,
Yes thats true, the word Pristine what is refered to as Base or DV in my post. There are very few istallations i have seen who have a separate Pristine env in the shop most have only DV. Thats what i meant in the post that it becomes difficult for developer to then find out if the issue is relate to bsae or custom code. I have been thru this situation in many of my projects.

Chan

 

[Remo Williams]

larry, just to make clear: i (correctly) assumed chan was referring to dev when (s)he said 'pristine objects'

 

[vbojan]

Just to mention…Some BSFNs (mostly master BSFNs) use processing options of hardcoded application and runtime version. If those BSFN are not modified they are going to read processing option’s data from vanilla application with corresponding version name, e.g. B4200310 called from P554210 version VERS001 will use processing option’s data from P4210 version VERS001. Keeping in synch processing options for each version of vanilla and copied app is not fun at all. That’s one of the reasons why we always modify vanilla apps.

Hope this helps,

Bojan

 

[BOster]

I guess I would be slightly more hesitant to modify a "vanilla" object if I didn't have a pristine environment, but I can't imagine NOT having a pristine environment either. I mean really, its not like it really adds to hardware requirement. A little config and a little disk space...

I guess my thought would be that if you plan to do any custom JDE development you damn well better have a pristine environment.

I guess I am luck in that we have a pristine environment/path code and a CNC department that does a really good job of making sure the pristine path code is at the same ESU level as all our other environments. So, if a mod is needed, I don't hesitate to mod the vanilla/pristine object since I always have the un-modified version if I need it and an environment to test it in.

 

[Zoltan_Gyimesi]

Hi Brian,

Generally there isn't Pristine environment on client site, but Pristine Central Objects generally exists on the server, so it is possible to compare against or Advanced Get it for examination.

Regards,

Zoltán

 

[Zoltan_Gyimesi]

Hi Bojan,

I am with you and the others.

Yesterday I was on the point of posting the same, that you had posted, but finally I forgot it and wanted to post it now.

By the way, in many installations we have we have extremly modified P421/P4310 applications, including many custom processing option parameter extensions.

Regards,

Zoltán

 

[Chan Rana]

When we modify the Base/Pristine the POs etc. is to be taken care, i would assume that these are the mandatory basic checks that should be done before you do the mod.
If you have a Pristine then you are lucky but i have rearly seen very few installation are willing to spend extra space for Pristine env.

 

[DBohner-(db)]

Getting off my horse, breaking a twig off the tree and drawing in the sand....

* Pristine Objects - from the Pristine Environment (usually PS###)
* Base Objects - Whatever is being used in Production (usually PD###)
* Developer Objects - Whatever the developer is using (usually DV### and could actually be different from PS, PD, DV, SV and other developer machines).....

* ESU Objects - some organizations create an ESU environment. It is a novelty - and could be considered a good practice. There are some consideration. PS is, usually, not the active code an organization went live with - it is usually the base code, without any ESU(s) applied (two worlds of thought: 1 - PS should be the ORIGINAL, Shipped Objects. 2 - PS should be the Code the organization went live with, Including ESUs and/or all ESUs applied to Production since go-live WITHOUT ANY MODIFICATIONS.) Production is whatever the organization is 'Live' with. Development and CRP can be ANYTHING in between. Some organizations consider an ESU environment whenever they consider an Update or Large ESU (usually, the environment temporary). They copy a complete Production (Objects, setup and data) to the ESU Environmet, then apply the Update/ESU. This would confirm the changes for Validation, before pursuing to Production.

And there you have some new vocabulary to review:
Pristine Object - PS Environment
Base Objects - Production Object
Development Objects - whatever's in the playground
CRP Objects - NEVER TO BE TRUSTED
ESU Objects - Came from an ESU, either applied to DV or an ESU environment.

Generally, those shops that do apply ESU's to Pristine - a few that I have worked with... apply them to Pristine AFTER they have been applied to Production.

I'll go back to riding a horse, enjoying the fresh breeze and wondering why it's called a North end of a South-bound horse, when the rider is usually headed West.

(db)

 

[Larry_Jones]

Thanks Daniel - good summary.

I will say though from my limited experience - I don't understand the point of having a Printine environment without any ESUs applied. As you ended with it should have the same ESUs that get applied to Production. Otherwise - what's the use?