Allowed Activities During Full Package Build

blah, blah, blah, blah, blah.

I'm howling reading this one.

Update packages work fine within limits. Of course 200+ update packages and your specs (pre 812) go to crap.

As for not allowing checkins during a build - well depends on when you build. Developers work 9 - 5 and CNC's work 24/7 so just build when the Developers have gone home or just use there 2 hour coffee break to do your packages (please no stones just tomatos).

In an "ideal" world we would check in all of our objects & versions, stop development, build our package and then deploy it. Yes, I do say ideal because this would be the best thing for the system but none of us live in this world and each environment is different so the short answer here is "Do what makes the most sense in your environment".
 
I would be very interested to see the results of any of Sue's environments
once she does build a full package. I had a client that had 90+ update
packages. We built a full package (lo and behold) the errors were thru the roof.
Full vs Update has been discussed for years.................I think we
should agree to disagree. If you are comfortable with how you are managing your
system then so be it


Barb Kramarski
 
Wow, Thanks guys!

I thank you all for your input. This has been a blast reading all of your input. I have to admit I have seen practically every situation you have portrayed here.

Currently, I am working two clients. The first one, which I mentioned in the initial post, is a large shop on Xe and megadevelopers and CNC, and they have an automated system for requesting packages and they disable the checkin button anytime a package build is going on. Oh, and they run Web client for all users.

The other client is also Xe and has a large user base but there are only a few developers and one part time CNC person who wants us off the system when he does a build and we just can't afford the down time right now. I think if he realized what his options were, he would probably be working less odd hours.

In anycase here's two cents....Developer's don't always work 9 to 5. And unfortunately, I have found - in two occasions anyway - that I knew more about the CNC than the CNC responsible party (can't bring myself to call them a CNCer).

Thanks ever so much - and don't stop talking about this post on my account.......
Ben again,
 
You, I guess, are new to this forum and JDE products. I guess that it makes sense why you lurk and are anonymous. Based on your illustrious well-informed posts (a grand total of 8) to this site, it's a pity that you have even bothered to post anything.

With your noggin, I'd be ashamed to post anything with my name on it too. If you were a consultant, noone would hire you based on these lame 8.

I lurk, I might not say too much - but with these really big, interesting threads - its time to weigh in and kick butt.

I would recommend RTFMs then instead of lurking. My sense is that you are either infamiliar with JDE products and/or you have never worked on a large ERP implementation.

Not sure how a package "forces developers" to understand CNC. However, most people with powerful roles in any ERP organization should have at least an inkling of knowledge of what CNC is and how it works.

What the hell does "powerful roles in...ERP organizations mean"? In larger IT shops (more than 10 working on ERP), there are developers (offshore, remote, local and skilled / unskilled) and there are CNC people. I would argue that a majority of the developers employed today have no concept of what a package builds means or how it works. And, to some extent, they shouldn't. It's there job to develop and to understand the code. There are probably a thousand development tools/languages on the market that they need to know, include RDA/FDA/SDA etc. Just getting developers familiar with the basics of checking in and checking out should be necessary. Sometimes this is a challenge for a lot of reasons I won't go into.



What is THIS about ? If you want a TPC form filled out, then create the right TPC form and assign it to the update package - not sure why your process wouldn't be able to cover partial updates to be honest


I don't know what TPC means; perhaps you could enlighten us on this TLA. [Did you make that up?] To point 1, it appears that you have limited experience so I'll go softly. I'll assume that your ignorance is due to the limited size of your IT organization. Change control forms are the type of forms that large bureacratic IT shops have to use to document a software change because they are mandated by law to do so. The mandate comes from Sarbanes-Oxley, the FDA, the DOD, or any of the other myriad of federal agencies requiring some silly paper form be completed whenever a developer puts in his 2 cents. These forms are typically used to justify an overly complex package build definition.



Save locations suck, and are a crutch for those who do not understand how CNC Architecture works. Just providing a SAVE location to a developer and shrugging your shoulders when that developer loses an object isn't a way to troubleshoot or help developers. CNC Administrators' role is to manage the objects in the system - the CNC administrator needs to be in CHARGE of all objects - not delegate the responsibility to a save location.

Where do I start with this one? Save Locations do not suck and the good developers not only know how to use them; they demand them. Let's see CNC=Configurable Network Computing. Where do you see the words PVC admin in CNC? Maybe with your skills this is the only kind of work you are capable of and, therefore, are permitted to work on by your manager. I am sure I am not the only one that has web servers, citrix servers, OS management, and server architecture to contend with.

What kind of a moron thinks he is adding value by knowing which objects are in what pathcode? JDE has had a nice piece of software since B73.1 that can do this nicely for you. It is called OL-OMW. You might want to crack that JDE book open.



In the respect that a full package catalogs the entire source tree - this is a correct statement. Probably the only truthful statement in this post.
"Source Tree" / "catalog"? Here's what you do, moron. Do a search on the term "source tree" and "catalog" on jdelist and peoplesoft.com. I may sometimes be mistaken but I don't make up ficticious JDE terms. You don't even know the distinction between a source directory and Central Objects.




I never recompress parent packages - just because you do update packages, doesn't necessitate a recompress - you just need a script to go through and silently install each update one at a time.
Speaking from experience, and I am pretty sure you don't have such a script, this is a crap strategy. I picture your customers as I write this note. I see the look on their face when they have to call you for support. Oh its ugly.....You're on their client for two hours installing packages. Thanks for validating my point.





Full packages are a snapshot in time of the entire tree. updates are a snapshot in time of a smaller number of objects. If you're going to quote the CNC and Architecture guide, do it right.

WTF does this mean? See above re: source tree. Just a tip: if by "source tree" you mean the pathcode directory on the dep server. Then loosely, you have half of the Central Objects moron - just the C code. The other half is spec's. Spec's do not get built into the dep server's runtime pathcode directory. They get built into the spec files for the package only. Here's a little tip: The package spec's come from the Central Objects database during the build not the "source tree".

Re JDE guides: I know one term you won't find in any JDE guide: "source tree".



We're not talking 8.12 - we're talking Xe and ERP 8.0. Not sure why this point is being made

RTFT: I asked Ben for his release. I have worked with JDE since B73.1 and I truly pity the companies that are stuck on the old releases. Particularly when the have to build packages over and over and over by morons like you.



Properly configured deployment servers in Xe can do a full build in an hour for a pathcode.
BS: Post your package build reports to prove it. Noone on this forum has ever done a full build in 1 hour.

However, an update package can take as little as 5 minutes to process.
Yes 5 minutes of computer time. That is correct. All the more reason not to spend 3 hours and 55 minutes to hear you pontificate on why the package didn't work as you expected.

I really don't mind teaching and explaining to developers and project managers about how CNC works - after all, thats my job - but it seems to you that informing others about how the system operates is a waste of time. ,

Of course you don't mind; that justifies your vial existence and measly paycheck. That justifies your 3:55 of pounding your chest with glib technical stupidity (also known as "mental m.............").



It seems to me that you have set yourself up to be easily replaced too - after all, if you're not teaching CNC nor are you managing your implementation - what ARE you doing in your organization ? I think your productivity can easily be replaced by a clockwork orange...

I manage it very effectively by not wasting my company's time and money. I put the money into computing assets and sound architecture. And that is why, moron, I have been paid well over six figures for the last 10 years. BTW, can I get a company phone number? I see an outsourcing company overseas in their near future. I can guaranteee a savings of 80% to 90%. Or, perhaps SAP.



Package builds are an important part of any development environment. Its just that usually, the process is called "source control" and "compiling". Anyone with an ounce of intelligence and enough experience to fill a gnats testicle should be able to understand that and relate what, to you, is a boring task and what is to everyone else a necessary part of their administrative role.

I would suggest that you look outside of JDE for YOUR next role - because it seems to me you have no idea of how to correctly manage a centrally located development environment - and your answers pretty much tell me you are a danger to your corporate IT environment.

Development manager's do "source control". To quote Colin: Blah, blah, blah.




Fat clients are NOT gone as far as Xe is concerned. Xe is going to be supported until 2013 - and ERP8.0 and Xe combined make up a pretty big market share of JDE installbase. Today, Web and reports are a nightmare performance issue under 8.9x and you need BIG box to run these functions. This has been a nightmare for years - and as I stated before, anyone who had the slightest investment in eliminating the terminal servers should have been wiped from the planet long ago - after all, they no longer work for JDE and we have to deal with their crap. But we cant change what has occurred. But sometimes its interesting to point out jerkoffs that post crap on here when they obviously understand nothing, and have "no time" to help their co-workers.

XE is old. JDE doesn't introduce new functions for it. Pathetic IT losers with limited skills love to stay on it because it justfies their "package build" mill kind of skills. They stay on it because either they love complacency or their company does. The reality is that just because Oracle says that XE will be supported until 2013, doesn't mean your company will benefit from that support. The word "Support" has a lot of definitions. Look no further than World. If you call JDE about a problem with World, they will answer the phone. World is supported; its supported by all of the extra non-productive employees and IT people at the companies that run it.
People like you love it because you are too lazy or too stupid to learn web so your company suffers at your expense. The web releases for 8.1x run faster than fat clients. Just because you have no experience with web is not my problem.


Note to JDELIST.com: anonxe's post is an example of the kind of post that degrades jdelist.com. Bozo's like anonxe can post anything without any limitation. Even though he has only 8 worthless posts; trained and informative contributors can't shut him up. With www.slashdot.org, flamebait posts like these get modded down to the point the poster can't post for a period of time until other posters mod them up. On the flip side, people that are consistently posting good helpful info get moderator points and can freely post anything.
 
Re: Allowed Activities During Full Package Build *DELETED*

Post deleted by ekempter
 
wow.

Who would have thought this simple question would have led to a holy war against package building duties ?!

There seems to be some pent-up frustration here amongst the CNC Administrator fraternity.

So - I have a question - how SHOULD JDE change their methodology as far as storing central objects and converting them to replicated objects - it just seems to me that very little has been done to OMW since its inception - perhaps EOne 9.0 will see a new method of development and object storage ?
 
This did turn into an interesting post.

I saw two questions directed at me.
1. Was performance impacted when we got over 200+ update packages.
A - I don't think so and it has been a few years since we got into that mess. There is very little use of our DV terminal servers and the Developers didn't complain. So not sure really.

2. Did we have lots of errors when we finally built a full package after all those updates?
A - no. If all update packages build clean, then theoretically the full will be clean too. Of course there are always one or two 'surprises' in DV only. PY and PD generally build clean. I remember one PD full mysteriously dropping a rather critical HR bsfn (that hadn't been touched in years) but we put that down to 'one of those things'.

And yes, we do have 4 full time CNC's but they generally have little to do with packages, except the PD deploy. As I said, we have a student managing code changes. He also generates tables and makes DD changes. The other 4 CNC's do other fun stuff like OCMs (47 environments), help Developers, support security apps (yes, we have lots of custom stuff for that) and the general odd tasks that CNC does.

Sue
 
I must admit that I do not know why this post should generate so much passion and aggression.

This is not the first post that I have seen where somebody has been "put down" in such a blatantly hostile way.

I thought there was supposed to be a moderator for this forum, and it makes me wonder whether they are performing that function.

We all have our own ways of working and understandings of how JDE works (or does not). We can all pick up and give tips to the community, and likewise the community has the option to either take those tips / comments on board or not.

Whether you agree with posts or not does not excuse some of the language that is being posted and I would hope that this could be a more tolerant site.

As for hiding behind annominity their are more people who use handles for user id's and hotmail accounts to hide themselves and who they work for and nobody seems to mind till somebody says something that they do not like.

I now have my steel helmet on and am in my fox hole awaiting "friendly fire".
 
Alright everybody please take a breath.

I can certainly understand how someone feels that their reputation is being attacked, when each of their points are totally picked apart. I, as a consultant, am very - let's say - rigorous about defending my reputation. However, when I am wrong, I am wrong. Now I'm not saying anyone is wrong here (remember I am the novice in CNC), but as a consultant, part of my reputation centers around respect. Respect for others and other's respect for me.

I have been wrong at a client's location before and as long as I can still learn and grow, I am still a desired commodity. I have never been back to a client site, where I have lost their respect or they have lost mine. And I have found that names (appropriate or not) is a very tough situation to recover from.

I try to never say anything about a person that I wouldn't be willing to say to their face - that attribute alone has gotten me many followup jobs.

I also have written many flaming letters. I learned that Abraham Lincoln wrote these kind of letters as well, but that he would set them aside - at least overnight and see if he still felt passionate enough to send unedited.

And if you ever need to tell someone to "Go To Heck" - Then try to tell them in such a way, that they look forward to the trip......

Ben again,
 
I'm sorry folks ,but "I wear short shorts!" I look very ugly in these short shorts, but I still know if I need to build a Full Package over an Update package.

All I know is; EGOs have never helped a cause. Please save the Owls in Denver and stop arguing over stupid crap!

Max
 
[ QUOTE ]
I'm sorry folks ,but "I wear short shorts!" I look very ugly in these short shorts, but I still know if I need to build a Full Package over an Update package.
Max

[/ QUOTE ]

MadMax

Just build a full package. It's not going to hurt, and it will probably fix your weird build issue. The old adage used to be, "you can never go wrong buying an IBM." The same can be applied to building a full package.
 
MadMax,
Just because it's so much fun, I am going to disagree with Greg.

The real answer, as with anything to do with E1, is 'it depends'.

Pros and Cons of Full Package
- pro - one shot, you have all the code in sync
- con - takes longer
- con - Developers need to be locked out from checkins from all code, not just those objects in an update package
- con - depending on where you have to deploy the code, this may not be practical time-wise

Update Packages
- pro - smaller, therefore quicker to build/deploy, etc
- con - need to manage associated full, ie recompress on a regular basis
- con - may have other related objects that are in not in update package so code changes don't show up properly with only an update

I'm sure there are a lot more pros and cons that the others can come up with....

But bottom line - you have to decide what is more practical and appropriate for your own business.

Good luck.

Sue
Xe SP23J1 Coexistent
 
[ QUOTE ]

2. Did we have lots of errors when we finally built a full package after all those updates?
A - no. If all update packages build clean, then theoretically the full will be clean too.

[/ QUOTE ]

Hi Sue

Yes, in THEORY if all the update packages build clean then the full will be ok too - but I've seen situations where the full build fails even though all the updates have been fine. It happens actually quite often - although usually doesn't take too long to discover why (usually a missing BSFN that didn't get promoted correctly or something similar). Yes, good policies and procedures would also prevent this from happening - but things can fall through the cracks in a large development environment.

So, I have a question Sue - what is the largest number of concurrent users to a single environment ? You state you have 47 environments with 800 concurrent users - so in theory you can't have more than about 40 or 50 concurrent users in your largest environment?

Sorry - didn't want to hijack this thread...
 
Hi Jon,
I think this thread long lost it's original purpose...

I did say 'theoretically', but in reality we don't have a lot of trouble with full packages, even after leaving them for a long time. The real reason is the 'fear factor'. Our Developers and Business Focal Users have been trained to test thoroughly in PY which points out missing objects. Since we only have one 6 hour outage for PD a week, there is a lot of concern over not causing an emergency PD update package to fix some bad code that moved up to PD. Getting our users off to deploy a package at any time of the day is challenging and gets a lot of publicity. No one wants to be responsible for that so they do test well in PY. For that reason we build the PY full before the PD full. So if PY is missing something, it might proactively indicate a problem for a PD full. But in reality this is not an issue for us. Very strict change control is the only way it works though.

We have 47 environments but that sounds worse than it is (except for OCMs). Ie for DV, we have WDV and JDV and we support multiple databases so we have 3 for each one of those. And so on. The PD path code is particularly exciting. The biggest environment is JPD which has around 500 concurrent users. The limitation is not JDE - it is what you have around it - we run a big iSeries (890 32-way), with WAS on the same box with 3 application servers for the JPD env.
Hope that was what you were looking for?

Sue
Xe SP23J1 Coexistent
 
Wow, this is long and quite the fun read!

Wow, this thread/post is freaking wicked!! I just read from top to bottom.

There is actually some really valuable information if you can sift through the crap. I cannot believe that with such a relatively small community of JDE CNC/Developers on this list that people would resort to name calling, but to each their own.

As for the really valuable discussion between Sue and Jon, here is my take.

Sue does a really stand up job working for a single company supporting a single release of the software. I am sure that anyone on this forum can learn much from her regarding Xe and CNC. I know I will get flamed for that, but I have heard nothing but good things about the work she does for the JDE community as well as her company.

Jon on the other hand has the benefit/or not, of supporting everything from Everest(lol) to 8.12 TR 8.x.x. at many many different sites. His perspective should be quite different, he is looking for the best way to setup a client so that he can
1. Get the job done
2. Use the KISS methodology
3. Be able to leave the client at some time and have them as a reference-able client

Everyone can learn so much from each other on forums like this if we can just stop and take a read from time to time and not think that our CNC doesn’t stink.

Now all of you morons get back to work. LOL

Kyle V <-Cause I ain’t ascared of using my real name!!
 
Re: Wow, this is long and quite the fun read!

[ QUOTE ]
Sue does a really stand up job working for a single company supporting a single release of the software. I am sure that anyone on this forum can learn much from her regarding Xe and CNC. I know I will get flamed for that, but I have heard nothing but good things about the work she does for the JDE community as well as her company.

[/ QUOTE ]

Oh - I totally agree. Sorry if it came over any other way, but I was just being inquisitive into Sue's environment (its a fascinating environment) - sorry, maybe I should have used the PM's instead. Sue, you do a great job with the community - thankyou - and you still owe me a beer...I think

I know I owe too many others beers. Thats why when I get to Quest Global, you always see me a little tipsy...! ;-}
 
Re: Wow, this is long and quite the fun read!

Thanks both of you for your compliments.
Note that even though we are on Xe, I am aware of the new tools functionality in the higher releases as a lot of it is stuff that we have asked for (due to our painful web client experience).

I totally agree that different opinions and knowledge is what makes this forum great. So long as they can be shared in a professional manner. I choose to ignore the rants.

Beers, either owed or owing can be sorted out at Collaborate. Though I prefer vodka cranberries.
smile.gif


Mark your calendars for Collaborate:
April 13-17, 2008
Colorado Convention Center, Denver, Colo

It's going to be a good one:
- in Denver so lots of JDE Oracle folks available
- overwhelmed for choice with sessions
- I am the 'Geek Meet' reception coordinator for this year (anyone interested in sponsoring? - if so that warrants a private message please)

Hope to see you all there.

Sue Shaw
Quest EnterpriseOne Advocacy Director
(the only true geek on the board)
 
I just read this thread, and my first reaction is Wow! :) I actually have something constructive to add. If you deploy a server package it will lock the BSFN kernel running on that server. This will cause all web users to be locked out until the deployment is finished. I believe that if a UBE is running, then the package deployment will hold the lock until the UBE is finished, then do the deployment. So the lock could be held for a long time. And not just for the path code you are deploying too either, it will lock out all web users for all path codes on that server. I've also attached a good spreadsheet that outlines what happens during an update package build. Hope this helps.

Andrew Dowdall
 

Attachments

  • 127704-PackageBuildFlow.xls
    133.5 KB · Views: 143
Thanks Alex!

I think this one line sums the whole thing up quite nicely...

"Basically, unless you are 100% sure, don't. ;-)"
 
Back
Top