• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

updating UBE versions on Windows Terminal Servers

Frosty the Coder

Legendary Poster
List:

Currently, when we change a UBE we go through the ritual of:

Checking into the deployment server
Checking into (each) WTS
Erasing checkout from (each) WTS

Is there another way (other than a package build)
of "pushing" the specs to the WTSs?

Does checking the modified version (NOT a mod'd
template) into the deployment server get the specs
updated on the enterprise server, or does the enterprise
server _only_ get updated w/a package build?

TIA

Gene Piekarski, Jr.

Corning Data Services
gpiekarski@corningdata.com
(716) 853-6215

"If you are what you eat
then I'm easy, fast, and cheap."
 
We are not a great user of TSE and have not come across this problem yet.
We are on B73.3.1, Oracle and Sun Solaris and the majority of our users are Fat clients.
For versions what we have found is:
1. Using the advanced row exit of Submit job, you can submit the version specs to the enterprise server. This is a job type of 0001 and your queue must be set up to accept this job type. This is only necessary if the version is called by the enterprise server.

2. For versions that are checked in these appear on the version list and if a user wishes to run this version a JIT instal of this version is done at that time.

3. In submitting a job the specs seem to be submitted from the workstation so versions that are not on the server appear to run - Is this correct?

Neil Mackenzie
I T Manager
Smiths Manufacturing (Pty) Ltd
Tel: +27 (0) 31 7194142
Fax +27 (0) 31 7194444
e-Mail: neil.mackenzie@smiths.co.za
 

got_to_love_jde

Reputable Poster
Gene,
Suggest you do an "Install" at the TSE instead of a check out. The install looks for other objects that might be needed for the UBE or APP to run. I know of no other way besides a package build to get objects over the the TSE.
I think if the version is new it will be JITI'd down to the enterprise server but it won't be JITI'd to the enterprise server if that version already existed and was now just being updated. For that reason i always make server packs for all version and template changes.
dave



NT 4.0 SP5, SQL 7.0, One World B7321 SP12.4
 

bwilkinson

Well Known Member
------ =_NextPart_000_01C04A3E.000F89E0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

One question on "001" jobs types , how do you setup a queue to accept =
this.

Other then a UDC Entry for the queue name, what other setup is available =
for queue's.

------------------------------------------------------------
Brian Wilkinson
QUICKIE MFG
856-829-7900 x143
Bwilkinson@quickie.com

JDEdwards OneWorld 7.332
Windows NT 4.0 Platform with SQL Server
------------------------------------------------------------
 

owguru

Well Known Member
Neil,

You are correct on #3. From a workstation, if you submit a ube to run on
the server, a copy of your local specs are copied and run on the server.
However, keep in mind these specs are copied to a temp location. The
enterprise server specs are not permanently updated. You need to use your
#1 suggestion below or build and deploy an update package containing the
version if you want it in the server specs (for a scheduled run maybe). I'm
an advocate for the package route on the TSE as well. With the
checkin/checkout method on multiple TSE's the original person talked about,
there are too many steps and thus more room for error...you miss one version
on one TSE, etc.

Another thing to remember is that if the version you call (even from a
workstation where it is "uploaded" to the server automatically), calls
another version during its run, the specs for the second version will be run
as they are in the server specs...no automatic install here. And chances
are the user is not going to go and install the second version in the submit
job application.

These are the little things that get you in OneWorld. I'm all for as few
packages as possible, but I believe in building and deploying update
packages on a regular basis to keep everything in sync. Versions are an
especially confusing topic and can be murder on an administrator. Each
customer is different, but they should all have a consistent process for
versions...

Many customers leave versions open for all or most users to create, change
and run. Some have it locked down so tight that you have to call a
developer to change a processing option (painful in the real world). I
don't have many opinions either way, but as an administrator you need a
plan.

...mini dissertation on versions and administration to follow...

If your users have a lot of power in the versions department, the key words
are training, training, training! This can mean turning them into
mini-CNC/development gurus with all the checkin/checkout knowledge and
understanding of how objects move around the system (for batch version,
which is what they're all concerned about anyway). Armed with this
information, they will still make your life hell with all the confusion. I
prefer to train their expectations. User-created versions are temporary,
typically containing processing option and data selection changes. If they
go to run their version next time and it's there (you don't go through and
delete all strangely named versions on a regular basis from the F983051) and
accessible (their machine has not been reinstalled since they created the
version and they are working on the same machine), great. If not, just make
a new one. If they need a version that will be run on the server or is more
complex, then give them a request process through a supervisor or
development to create and/or move the version. This is where you, the
admin, performs a service for the user by building and deploying a package.

If you take all the power away from users and force them to make
"development" requests, you are in the big development cycle anyway...enjoy!

In the end, especially for you World lovers out there, keep in mind you
aren't in Kansas anymore. Versions were simpler in World...everything was
simpler! But all the moving parts are what make OneWorld so much fun :)


>From: Neil Mackenzie <Neil.Mackenzie@smiths.co.za>
>Reply-To: jdelist@jdelist.com
>To: jdelistml@jdelist.com
>Subject: Re: updating UBE versions on Windows Terminal Servers ~~737:765
>Date: Thu, 9 Nov 2000 05:41:49 -0800 (PST)
>
>We are not a great user of TSE and have not come across this problem yet.
>We are on B73.3.1, Oracle and Sun Solaris and the majority of our users are
>Fat clients.
>For versions what we have found is:
>1. Using the advanced row exit of Submit job, you can submit the version
>specs to the enterprise server. This is a job type of 0001 and your queue
>must be set up to accept this job type. This is only necessary if the
>version is called by the enterprise server.
>
>2. For versions that are checked in these appear on the version list and if
>a user wishes to run this version a JIT instal of this version is done at
>that time.
>
>3. In submitting a job the specs seem to be submitted from the workstation
>so versions that are not on the server appear to run - Is this correct?
>
>Neil Mackenzie
>I T Manager
>Smiths Manufacturing (Pty) Ltd
>Tel: +27 (0) 31 7194142
>Fax +27 (0) 31 7194444
>e-Mail: neil.mackenzie@smiths.co.za
>
>
>
>
>--------------------------
>To view this thread, visit the JDEList forum at:
>http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=OW&Number=765
>*************************************************************
>This is the JDEList One World / XE Mailing List.
>Archives and information on how to SUBSCRIBE, and
>UNSUBSCRIBE can be found at http://www.JDELIST.com
>*************************************************************
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at
http://profiles.msn.com.
 
Top