I'm having trouble with the Migration process from OI9 into OI10.2.1 where it just crashes and disappears at some point in the Migrating Entities task with no info. Unfortunately this part takes hours and I can't tell at which point it fails, as the log hasn't been written to disk yet. The IDE is then inoperable, due to migrated promoted events that have not yet been compiled.

So I tried to use the Selected Entities option to just do a partial migration of core components - but even this crashes before offering a selection! It looks like an Open call (RTP9) is recursing itself -

Both systems are just on C: drive and run in Local Mode without an LH service.

Any ideas how to troubleshoot?

Cheers, M@

Vernon Systems

Any ideas how to troubleshoot?

Vernon Systems

M@,

I recently encountered very nearly the same issue. I never created a profile log because I was able to figure out that it was due to a rogue (or missing) MFS. My resolution was to make sure I had the MFS migrated first or I removed it from tables that weren't supposed to have it. In some cases, the OI 9 DBT did not reference the MFS but the Media Map did. So when I attached those tables in OI 10 the new DBT referenced the MFS and created many problems.

Don Bakke

SRP Computer Solutions, Inc.

Hi M@,

Don's point about an MFS is a good one - If it doesn't turn out to be that then check for aliased tables in your application as well - RTP9 (i.e. the Open statement) does a lot of work chasing those, and seems like a prime candidate for this too.

» The IDE is then inoperable, due to migrated promoted events that have not yet been compiled.

This concerns me - why would these be an issue if they've not been compiled? Also - are they application-aware? i.e. when they run are they specific to your app (and descendants), or will they affect components that belong to the SYSPROG application as well?

Cheers,

Carl Pates

Don's point about an MFS is a good one - If it doesn't turn out to be that then check for aliased tables in your application as well - RTP9 (i.e. the Open statement) does a lot of work chasing those, and seems like a prime candidate for this too.

Good ideas, thanks.

Yes - for the MFS, I just created a simple pass-through to the next FS before migrating.

We do have a Qfile that is initialised in the DBT. I detached that before starting up the migration window. This doesn't appear to have made a difference though..

» The IDE is then inoperable, due to migrated promoted events that have not yet been compiled.

This concerns me - why would these be an issue if they've not been compiled? Also - are they application-aware? i.e. when they run are they specific to your app (and descendants), or will they affect components that belong to the SYSPROG application as well?

The promoted events are defined at application level, but the IDE seems to be running in the context of the application account and picks them up. It seems I'll have to put some logic into the promoted events to check what application the CtrlEntId actually belongs to - unless there's a proper way I'm not aware of?

I guess it's not a problem in OI9 as Application Manager is not a native OI window.

Cheers, M@

Vernon Systems

Hi M@,

So is it OK if you remove the MFS?

The promoted events are defined at application level, but the IDE seems to be running in the context of the application account and picks them up. It seems I'll have to put some logic into the promoted events to check what application the CtrlEntId actually belongs to - unless there's a proper way I'm not aware of?

I guess it's not a problem in OI9 as Application Manager is not a native OI window.

Below is some code from a PE handler I wrote way back when that checks to see if a form belongs in an app that descends from the ZZX app (which is where the Sprezz framework PE's and components live). Once we know if it should be covered by the PE then it sets a UDP so it doesn't have to do all this work again. Even in v9 it was possible to kill the DB Manager and System Editor ++ etc.

///////////////////////////////////////////////////////////////////////////////

///////////////////////////////////////////////////////////////////////////////



checkWindowApp: ; *    ( handleEvent )

                ; * -> ( handleEvent )

   * // This subroutine checks a window to see if it should be handled by our

   * // promoted event handler or not. Basically we don't want to handle 

   * // events for any window/control that is higher in the application event

   * // chain than ZZX.  This is so we don't clobber system windows like

   * // the Table Builder or Database Manager etc.

   * //

   * // To flag if window should be handled we set a UDP (User Defined 

   * // Property) on the window called @_ZZX_PE_.  If this is TRUE then

   * // we handle the event.  If it's FALSE then we don't. If it's null then

   * // we do the check and set the UDP with the results.

   

   handleEvent = get_Property( @window, ZZX_PE_UDP$ )

   if len( handleEvent ) then

      * // Fine, we've already set it so return

      null

   end else

      * // Look back up the event chain to see when we actually find the 

      * // form definition ...

      

      handleEvent = FALSE$

      winID       = @window[1,"*"] ; * // Remove instance number if it's there

      

      open "SYSREPOS" to hSysRepos then

      

         xCount = count( @appID, @fm ) + 1

         gotZZX = FALSE$

         

         for x = 1 to xCount

            

            appID = @appID<x>

            if ( appID = "ZZX" ) then

               gotZZX = TRUE$

            end

            

            reposID = appID  : "*OIWINEXE**" : winID

            read reposRec from hSysRepos, reposID then

               * // We found it so what level was it

               

               if ( gotZZX ) then

                  if ( appID = "ZZX" ) then

                     handleEvent = TRUE$

                  end else

                     * // Must be above ZZX in the app chain so 

                     * // leave it alone...

                     null

                  end

               end else

                  * // Must be below ZZX so we handle it...

                  handleEvent = TRUE$

               end

               

               x = xCount ; * // break ...

               

            end else

               @file.error = "" ; * // Don't care....

            end

            

         next

         

         * // Update the UDP

         

         call set_Property( @window, ZZX_PE_UDP$, handleEvent )

      

      end else

         * // That's a bit of a problem!

         errorText = zzx_Utility( "FSERROR" )

         errorText = "Error opening Repository table [" : errorText : "]"

         call set_Status( TRUE$, errorText )

         abort = TRUE$

      end

      

   end

   

return

Carl Pates

The fact that your conversion shows Open being called recursively makes me suspect some sort of alias.

RTP 9 uses the Open statement internally to try to open MD or VOC to look for qpointers. The logic is something like

Open the file - if that fails, Open MD / voc so we can look for a qpointer. Maybe MD or Voc are not there?

Also,

RTP9 will try to install every mfs on a table unless the mfs is in a system variable listing those that have installed. It calls the mfs with the INSTALL code. If the mfs returns status = 1 then the mfs is added to the list of installed mfses. So if you have an mfs which opens a table on the install then that might be the issue, but I think you would see the mfs in the profile log recursion chain along with RTP9

Hi Carl,

So is it OK if you remove the MFS?

Well, there's over 700 data files with the MFS installed so I'm trying to avoid that if possible. It isn't on any system files though. I suppose I could remove them from a copy of the DBT file and use that temporarily !??

Below is some code from a PE handler I wrote way back when that checks to see if a form belongs in an app that descends from the ZZX app (which is where the Sprezz framework PE's and components live). Once we know if it should be covered by the PE then it sets a UDP so it doesn't have to do all this work again. Even in v9 it was possible to kill the DB Manager and System Editor ++ etc.

Ah, nice - thanks! This will fit nicely in our centralised promoted event handler.

Cheers, M@

Vernon Systems

Hi Bob,

RTP9 uses the Open statement internally to try to open MD or VOC to look for qpointers. The logic is something like

Open the file - if that fails, Open MD / voc so we can look for a qpointer.

Maybe MD or Voc are not there?

Yeap, that was it - thanks! MD in REVBOOT wasn't attached; nor VOC in AREV_DIR. It also seems to require SYSALIASES in AREV_DIR.

There appears to be a dependence on AREV_DIR even for pure OI apps. Without these system files attached, any attempted access to a file that isn't attached will just crash OI, rather than returning an error. Eg

RUN LIST_KEYS 'DUMP_FIX_TEMP'

(without yet having fixed any GFEs)

Cheers, M@

Vernon Systems

View this thread on the Works forum...