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.