delete a folder with a space at the end of the name

A backup / restore created a folder with a space at the end of the name which was causing all types of problems with package builds on a new deployment server.

Command below to delete it.

note that dir /w showed the space at the end of the name

rmdir "\\?\c:\JDEdwardsOneWorld "

8.98 web dev feature

Where do I start…

You definitely cannot install the H4A61_setup.exe if you have WAS6.0 locally.  Note that you will not get any error messages or anything, it’ll just fail.

You can go to the WASHOME\bin dir and run command “versionInfo.bat” file and it will tell you the exact version of the local WAS express product.

Then run the associated install pgm from \\DEPSERVER\E812\OneWorld Client Install\ThirdParty\WebDevFeature\ dir.

Note that you can do this at anytime and the correct webdev feature will be installed, even if u did not include it in the package build.

There are some command line options for the InstallShield program to help u too:

H4A61_setup.exe -is:javaconsole -is:log c:\temp\install.log

Also change your TEMP and TMP env variables to something a little shorter

Also, there is a know issue where the WAS6 does not get uninstalled properly before installing WAS61, which will ensure that nothing will ever work again.

See this for instructions for manually removing WAS6: uninstalling Websphere Express 6.0

blank reports from DEP server after 8.98.1.1 install

All reports (package build etc) from all environments produced blanks…  At least it was a couple of pages of blanks, and it had the underlines too – helpful.  Problem was, I could not fill in all of the blanks…  No matter how good my imagination was.

This turned out to me missing resource dir from the deployment server system dir.  None at all!

I copied it in from a new 8.98 fatty and all is good now.

WAS6 web server for non default profile

Okay, so now I have a real problem.

Server Manager makes a lot of things easy, but makes a lot of things hard at the same time.  It takes away that level of control that you sometimes need.

For example, I use the transaction server for RTEs out of E1.  Previously I created an additional profile (non federated) for my RTE functionality.  This was my preference to keep it all separate.  It all worked well back in 8.96.2.0…  But I try to use SM for the install in 8.98.1.1 and it was a webserver!!  What, I don’t need a webserver…

So now I have to follow complicated instructions here http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp for creating a web server for a non default profile, or maybe just create the RTE in the default profile (which I think that I will do).

AIX 8.98 install

Wow, what a time I’m having with an AIX 8.98 installation.  I’m going for 8.98.1.1, and have had issues.  I believe that if I was following instructions, they would tell me…  You need to run the E812ToolsEnvSetup.sh from your $SYSTEM\bin32 dir so that all of the libraries can be found.  I was manually hacking into the .oneworld – which is not the solution.

Note another little thing that needed to be done.  When introducing SM to all of my servers, I needed to add the network deployment manager so that all of my network deployed applications could be seen.  This took a tres long time, but the results are worth it.  I have this complete remote management ability in SM – v cool.

start ODBC control panel

odbccp32.cpl

Package deployment

We were hesitating last night to deploy a package on a server that had active SBS jobs running.  We were doing a UA package and saw that there were PD SBS jobs running.

It seems that you can do this, supporting (and not so supporting) documentation is below about the 812 package deployment process.

SBS running

An active subsystem job that is constantly running with a processing status is seen by the deployment as a job that it can not put on hold.  This requires end users to manually stop any 'processing' subsystem jobs so that a package deployment can be successfully completed.  A full lock on the files being changed by the deployment is required and this requires a hold on all jobs in the queue and kernel processes on the logic server.

Recoverable failed deployments

Good news is that the package can be redeployed at anytime (they are on 8.96.1.5)

This issue is fixed in BUG:8356917 (Tools Release 8.96.1.3 or higher) in which user do not need to restart services in order to unlock the server. If the Package deployment hangs due to certain interuptions e.g. long running business functions,subsystem jobs, UBEs currently running, etc, user can resubmit the Package Deployment UBE R98825D by clicking the Deploy button in Package Deploy application after those interuptions has fininshed and the system will do a clean up to unlock the locks and re-deploy the package.

Package deploy notes.

The solution is based on the existing process of how the server deployment process works.  Once the R98825D is kicked off, the deployment process signals all kernels on the server to go into a wait status.  Any job or process currently running will continue to process to completion, however, any process or job that is in the queue will be put on hold.
The end effect on end users is that they will ultimately not be able to process anything that uses the logic server (i.e. BSFNS mapped to the server, UBE jobs, Scheduled Jobs) during the time it takes for the deployment to finish.  Update packages would be much faster and full packages can take more time depending on hardware speed and disk I/O.
With this effect occurring, it is not recommended that clients deploy packages during normal hours of operation in a production environment.  The effect on changes to the specs and business libraries on dependent processes still waiting in the queue for after the deploy finishes could cause unexpected results.  For instance, if a transaction requires 5 functions to run and they are dependent on each other in the process then it would be possible that a deployment submitted while the first function is running could change the outcome of the remaining functions based on changes to the objects being used.   For this reason, it is recommended that production deployments be scheduled during a down time or during a slow period where end users are limited or doing read only type processes.
A true 24/7 shop may require a unique or custom solution to hot swap the servers to provide minimal downtime.  This is not supported by GSC officially and should be referred to our field support or business partners for official support of these types of solutions.  Even with a hot swap type solution, ultimately end users will be impacted and transactional processes may be impacted.
Clients that are the least affected by deployments to a logic server are those running a true fat client setup which is supported through the 8.10 release.  A Citrix or Terminal Server setup has the same negative impact on end users like HTML users normally since OCMs would default business functions to run on the server.  Running business functions locally in a terminal server setup can make your end users less impacted by deployment but will also negatively impact performance and the total number of users that can run concurrently on those machines.  HTML users, which is the only option in 8.11 and above will always be negatively impacted by deployments and this is the reason why the subject ofdeployment recommendations has more recently become an important topic with the EnterpriseOne client base.
Other ideas to help minimize impact on a production system include using multifoundation or separate logic servers for DV and PY versus a PD system.  The deployment of a package to DV on the same machine as PD sharing the same port would have the same effect of locking down all kernels and negatively impacting productions users.  The use of separate ports on the same logic server can effectively separate a production pathcode from deployment events occurring in other pathcodes.
Some enhancements to the deployment process seen in 8.96_A1 and above is the ability for a deployment process that is hung due to long running business functions to be resubmitted and recover any held kernel processes.  This will help minimize the need to refresh services if a deployment process hangs or fails due to network failures.  Simply rerunning the R98825D will accomplish this in 8.96_A1 and above.
Update 2/7/08 -- Two new SARs have been entered to address issues with the new requirements around the package deployment.