Object Modification when Upgrading from V8 to V11

[Anon Anon]

The good news and the bad news are the same: we are upgrading from Version 8 to Version 11.

 

One of the major challenges that we see are the number of functions whose operation changed between the versions (most notably from V8 to V9) and how to approach identifying and making the needed object modifications across all of our clients.  After review of theRelease Notes Version 11.2and predecessors and focusing on modifications we have a list of about 20 functions that may need to be addressed.  As an example, here are three changes that will most likely affect us:

1. The Values of Script Variables That Are Set with :PSET Are Now Only Passed on to the Next Workflows One Level Above

2. :RSET statements automatically create object values

3. Static Variable objects now include 5 value columns. For the script element :PUT_VAR, this means that values that include one or several commas and should be written in one column must always be enclosed in single-quote or double-quote characters.

 

Automic has provided SQL to perform queries for some of the changes to help with impact analysis but unfortunately they have not offered an all-inclusive set.  We can obviously use the UI’s Search dialog to locate base usage of Script statements and functions in the Process tabs.  Also we will most likely use Philipp Elmer’sSQL: grep in Process tabsand maybe a few others from his excellent site.  

However there is little offered by Automic to assist in actual analysis of how something is used and then actually making the required object modification.  This appears to leave us in the position of using brute force to accomplish the needed changes.   All that they appear to offer for the actual remediation is referencing phrases like “. . you will have to adjust the affected objects manually . .” and “. . recommends renaming all existing script and object variables with this name . .”  I am not faulting them as I cannot even conceive of a means to do this programmatically.  

 

We have a bit less than 150,000 objects in our single production client.  We have seven other non-production clients that contain copies of some or most all of the production objects plus ones that are unique to those clients.  Obviously performing this kind of analysis and remediation manually across our entire inventory is rather daunting.

 

I would really appreciate hearing about how others have addressed this issue when upgrading versions or any ideas or approaches that you can offer.

 

Thank you very much, Mark

[laura_albrecht_automic]

What sort of timeframe are you looking at doing the upgrade Mark?  And exactly what is the scope of some of the situations you reference above?  For example, how extensively IS PSET used?  I also cannot conceive of how this could be done programatically.  We had discouraged the use of PSET because some of it's uses had caused system performance problems so we didn't get hit by this one really.

Only solution I can think of, if you have the time, is to address all the PSET issues PRIOR to the upgrade.

I'm not sure I understand the impact of the RSET one you mentioned.  

I wish I had a better suggestions / solutions for you.  

[Pete Wirfs]

We do not use PSET and we have less than 3,000 objects, so I'm not even close to being in your shoes.  

Your situation reminds me of the Y2K project that I worked on for almost 3 years.   First we came up with multiple solutions to the problem, documented how they would work, and documented the relative cost/benefit of implementing each solution.  Then we methodically went through a triage process with our application inventory to decide what would be the best-fit solution for each application.   We also had to decide how to "chunk up" the application work so it could be phased into production one piece at a time.  Once these decisions had been made, then we were able to farm out the code renovation work (the brute force part).

[Anon Anon]

Thanks for the reply.

The Project Manager pulled a date (from I don’t know where) of November.  So far it looks that we can perform all of the remediation under V8 prior to the actual upgrade but it certainly won’t be pretty.  I agree that there appears to be little chance of automating much, if any, of this. 

In the production Client we have 159 uses of PSET and 126 of RSET.

I still don’t have a V11 test system available to verify the operation of anything that I've read about so for me it’s currently my interpretation of the release notes and the documentation.

Full RSET information from release notes for V9:

:RSET statements automatically create object values 

When you assign :SET and :RSET statements the same script variable with different values, their values will be set by those :SET and :RSET statements when the job is executed. However, if the job is restarted, the values of both variables will be set by the :SET statement. This is because :RSET statements automatically create object values and :SET statements automatically save the value for a restart. This is a change in behavior from v8, where :RSET statements did not create object values.

That means to me that we will have to determine if that statement’s use in any process was being used to pass a variable's value between its Pre Process or Process to its Post Process or its value is to be “saved” for use on a restart.

For PSET we will need to determine how “global” is the use of the variable within a Workflow and all of its tasks. 

Not looking forward to this, but to quote Nietzsche "that which doesn't kill us makes us stronger!" :'(

Thanks again.

Mark