There has been an issue discovered when installing on the AIX machine. This is a known issue with respect to running an Installshield Multi-Platform installer on an AIX 5.3 machine.
If the process creates a core dump when executing the installation of the agent on your AIX 5.3 machine. Here is the important information from the core dump of the java process:
SIGSEGV received at 0x362220e4 in /opt/JDEdwards/Install/ismp001/libaixppk.so. Processing terminated.
If you see the above in the dump file then use this link to solve the problem. Follow the instructions closely and this should allow you to install the agent. It is a fix to the libaixppk.so for ISMP. Here is the link:
http://knowledge.macrovision.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q111262&sliceId=
Thursday, March 20, 2008
Thursday, March 13, 2008
iSeries EnterpriseOne Enterprise Server - Change Component processing by the Management Agent
The management of an EnterpriseOne Enterprise Server is handled on all supported platforms. This tips section will speak to the iSeries specific Change Component process. As most know, the process for doing anything on the iSeries (AS400) machine is quite different than any other platform. I will talk to the steps (commands) that are used during the process of changing out a tools release using Server Manager.
Processing that occurs when you choose to register a pre-8.97 version of the Enterprise Server with Server Manager and then go to upgrade your server tools code to 8.97, Server Manager will automatically save the pre-8.97 version into a software component. That software component could subsequently be used to change from the current version back to the pre-8.97 version. So, Server Manager will allow you to roll back to that version that was registered when you first installed and setup your management domain. This is not specific functionality for the iSeries, but is good information to note as we understand what processing is going on in Server Manager. (NOTE: All work for any instance is done inside the agents jde_home\targets\"instancename" directory. Remember this note throughout the processing of the change component.)
Now, what happens during the processing to change out an iSeries EnterpriseOne Enterprise Server's tools code? First thing to note is that logging is fairly detailed as to the actual commands that are issued to the iSeries. Additionally, the return messages, even when successful, are logged to the agents log file. This is good for all troubleshooting. Second thing to note, as with any platform, the processing of changing out a tools release does a backup of the release being changed out as a first step into a temporary folder. This is for rollback purposes. If a step in the process of changing out the tools release fails a rollback will be executed. Now that you have these notes in the back of your mind, we can talk about the steps in the process.
First in processing is the backup itself. A save file is created for both the QSYS and IFS file system related to the EnterpriseOne code base, CRTSAVF commands. Next, if a printqueue directory exists in the IFS, a temp directory is created (MKDIR command) and the contents "moved" to the temp dir (MOV command). The reason for the quotes around the moved is based on the fact that the contents are not copied as this operation could take very long if the printqueue directory is large. The iSeries can "move" ifs objects much more efficiently than copy them. Next, a temp directory is created for the ini directory (MKDIR) and the ini file is "moved" to the temp directory just created (MOV command). Moved for consistency with the printqueue more than anything. Next, the actual save of the system library (i.e. - E812SYS) and the ifs directory (i.e. - E812SYS) is executed (SAVLIB command). Next each of the save files is copied into the IFS jde_home\targets\\ using the copy stream file command (CPYTOSTMF command). Now the backup of the existing system is complete.
Second in processing is replacing the old with the new. First we extract the software components contents into a temp directory. The contents that are important to Server Manager are scf-manifest.xml, system(SAVF) and krnlspec(SAVF). Next, the system library (E812SYS) is deleted (DLTLIB command). An important note here is that if any jobs have a lock on this library at this time, the DLTLIB will fail and the change will throw an Exception. So, make sure no locks are present before beginning this process. Next, a save file for the system library is created in a job QTEMP library (CRTSAVF command). Next, the extracted save file is copied into the newly created save file for the system library using copy from stream file (CPYFROMSTMF commands). Now we have the new qsys system save file that can be restored. Next, the system libarary is restored (RSTLIB command). A note here is that the library the system is restored into is the same name as the original library. Next, the creation of a subsystem (SBSD) is executed (CRTOWSBS command). Next, changing the data area BUILD_VER (DTAARA) in the system library is necessary (CHGDTAARA command). This matches the restored library name with the data area information. Next, delete the IFS E812sys directory (Java IFS file system utilities) . Next, a save file for the system folder is created in a job QTEMP library (CRTSAVF command). Next, the extracted save file is copied into the newly created save file for the system folder using copy from stream file (CPYFROMSTMF commands). Now we have the new ifs folder save file that can be restored. Next, the ifs folder (i.e. - E812SYS) folder is created. Next, the ifs folder changes owner to ONEWORLD (CHGOWN command). Next, the ifs folder is restored (RST command). Next, is the move of the printqueue and ini folders and contents. First make a directory for printqueue (MKDIR command). Move the contents into the new directory from the backup location (MOV command). Then change ownership to ONEWORLD (CHGOWN command). Second make a directory for ini (MKDIR command). Move the contents from the backup directory into the new directory, should just be jde.ini (MOV command). Then change ownership to ONEWORLD (CHGOWN command). Next, get the version value from the PTF.LOG file and set it for the instance. This is so we know the version of EnterpriseOne based on the value in this file.
So, if all the above steps complete successfully, we now have a new version of the EnterpriseOne Enterprise Server ready to run. Otherwise, at any point in the process that fails the backup system will be restored based on where in the process the failure occurs. Hence, there is as much level of commitment control going on as possible. Basically, the IFS and QSYS steps are tracked and then if all these are past then a full rollback should be attempted. I will not go through all possble scenarios with the rollback, but you will see the commands run to execute the rollback the same as the above steps.
Processing the iSeries EnterpriseOne Enterprise Server changeComponent is quite different than any other platforms Enterprise server, but the model is the same. Meaning that Server Manager will use common models for install, change and uninstall throughout the processing of all the EnterpriseOne server types.
Processing that occurs when you choose to register a pre-8.97 version of the Enterprise Server with Server Manager and then go to upgrade your server tools code to 8.97, Server Manager will automatically save the pre-8.97 version into a software component. That software component could subsequently be used to change from the current version back to the pre-8.97 version. So, Server Manager will allow you to roll back to that version that was registered when you first installed and setup your management domain. This is not specific functionality for the iSeries, but is good information to note as we understand what processing is going on in Server Manager. (NOTE: All work for any instance is done inside the agents jde_home\targets\"instancename" directory. Remember this note throughout the processing of the change component.)
Now, what happens during the processing to change out an iSeries EnterpriseOne Enterprise Server's tools code? First thing to note is that logging is fairly detailed as to the actual commands that are issued to the iSeries. Additionally, the return messages, even when successful, are logged to the agents log file. This is good for all troubleshooting. Second thing to note, as with any platform, the processing of changing out a tools release does a backup of the release being changed out as a first step into a temporary folder. This is for rollback purposes. If a step in the process of changing out the tools release fails a rollback will be executed. Now that you have these notes in the back of your mind, we can talk about the steps in the process.
First in processing is the backup itself. A save file is created for both the QSYS and IFS file system related to the EnterpriseOne code base, CRTSAVF commands. Next, if a printqueue directory exists in the IFS, a temp directory is created (MKDIR command) and the contents "moved" to the temp dir (MOV command). The reason for the quotes around the moved is based on the fact that the contents are not copied as this operation could take very long if the printqueue directory is large. The iSeries can "move" ifs objects much more efficiently than copy them. Next, a temp directory is created for the ini directory (MKDIR) and the ini file is "moved" to the temp directory just created (MOV command). Moved for consistency with the printqueue more than anything. Next, the actual save of the system library (i.e. - E812SYS) and the ifs directory (i.e. - E812SYS) is executed (SAVLIB command). Next each of the save files is copied into the IFS jde_home\targets\
Second in processing is replacing the old with the new. First we extract the software components contents into a temp directory. The contents that are important to Server Manager are scf-manifest.xml, system(SAVF) and krnlspec(SAVF). Next, the system library (E812SYS) is deleted (DLTLIB command). An important note here is that if any jobs have a lock on this library at this time, the DLTLIB will fail and the change will throw an Exception. So, make sure no locks are present before beginning this process. Next, a save file for the system library is created in a job QTEMP library (CRTSAVF command). Next, the extracted save file is copied into the newly created save file for the system library using copy from stream file (CPYFROMSTMF commands). Now we have the new qsys system save file that can be restored. Next, the system libarary is restored (RSTLIB command). A note here is that the library the system is restored into is the same name as the original library. Next, the creation of a subsystem (SBSD) is executed (CRTOWSBS command). Next, changing the data area BUILD_VER (DTAARA) in the system library is necessary (CHGDTAARA command). This matches the restored library name with the data area information. Next, delete the IFS E812sys directory (Java IFS file system utilities) . Next, a save file for the system folder is created in a job QTEMP library (CRTSAVF command). Next, the extracted save file is copied into the newly created save file for the system folder using copy from stream file (CPYFROMSTMF commands). Now we have the new ifs folder save file that can be restored. Next, the ifs folder (i.e. - E812SYS) folder is created. Next, the ifs folder changes owner to ONEWORLD (CHGOWN command). Next, the ifs folder is restored (RST command). Next, is the move of the printqueue and ini folders and contents. First make a directory for printqueue (MKDIR command). Move the contents into the new directory from the backup location (MOV command). Then change ownership to ONEWORLD (CHGOWN command). Second make a directory for ini (MKDIR command). Move the contents from the backup directory into the new directory, should just be jde.ini (MOV command). Then change ownership to ONEWORLD (CHGOWN command). Next, get the version value from the PTF.LOG file and set it for the instance. This is so we know the version of EnterpriseOne based on the value in this file.
So, if all the above steps complete successfully, we now have a new version of the EnterpriseOne Enterprise Server ready to run. Otherwise, at any point in the process that fails the backup system will be restored based on where in the process the failure occurs. Hence, there is as much level of commitment control going on as possible. Basically, the IFS and QSYS steps are tracked and then if all these are past then a full rollback should be attempted. I will not go through all possble scenarios with the rollback, but you will see the commands run to execute the rollback the same as the above steps.
Processing the iSeries EnterpriseOne Enterprise Server changeComponent is quite different than any other platforms Enterprise server, but the model is the same. Meaning that Server Manager will use common models for install, change and uninstall throughout the processing of all the EnterpriseOne server types.
Subscribe to:
Posts (Atom)
Posts
