We are having problems deploying applications from OI 3.5.

All entities are extracted OK but at the end of the extract entities phase you get an FS100 error on the very last entity extracted.

I can only assume the FS100 is caused after the entity extract phase by a cleanup process or the like. Unfortunately this probably minor error prevents a successful deployment.

What I need to do is change RDKEXTRACT to ignore the FS100 by doing a SET_STATUS(0), but it is impossible to recompile the RDKEXTRACT stproc since the object code cannot be overwritten.

Can you please advise either or both of the following:

1. How can I modify RDKEXTRACT?

2. Any ideas on what might be causing the FS100 at the end of the extract phase?

Regards,

Andrew Gebbett

PS Any replies to my last post regarding deploying from OI 3.5 on an NT 4 Workstation. We seem to be having a lot of problems with deploy in OI 3.5.

There is a record in SYSENV called SYSPROCNAMES. Remove the program from the list, save and restart OI.

[email protected]

Sprezzatura, Inc.

Andrew,

PS Any replies to my last post regarding deploying from OI 3.5 on an NT 4 Workstation.

This is logged in our SPR system as spr id#JDUE3PNRTK. The only workaround that I know for this problem is to deploy from a win95 or 3.x machine.

You can email me at [email protected] for an update any time.

John Revelation

Andrew,

FS100 is Record does not exist. I generally see this error when I am doing table operations on tables that do not have dictionaries, or when I've already attached a dictionary.

What is the entity that OI is trying to extract? Is it a real entity?

Can you run/Edit the entity in the Development system?

If the entity is os file (dll/exe) where is it located.

John Revelation

I have put a debug in RDKEXTRACT at the following point:

 

*

* Phase III:  Copy the entities themselves, one-at-a-time

*             into the target repository

*

If errorPhase ⇐ SETPHASE_PHASE_EXTRACT$ Then

Flag   =RDK_GasGauge(GG_SETSECTION$, SETPHASE_PHASE_EXTRACT$)

RDKExtractEntities(deployDef, releaseId, errorItems)

errStat=get_status(statCode)  

debug 

 

When the debug statement is reached the following values are present: 

errstat is set to 1(no surprise!)

statCode is set to FS100:@FM:D:\OINSIGHT (ditto)

@FILE_ERROR is set to 100:@FM:SYSPROG*:@VM:SYSREPO (relevant?)

 

If I add a SET_STATUS(0) to clear the error then the process goes straight to 'Extraction succeeded' without building the deployed app's repository indexes. So it would seem whatever the problem is the RDKextPrepApplication stproc does not like it!

 

As I stated before I do not believe this error is caused by an entity since it does not occur _during_ the entity extraction but at the end. If you set the last entity to be extracted to non-publishable then the error simply moves to the previous entity. I believe the problem occurs in RDKEXTRACTENTITIES _after_ all the entities have been extracted.

 

BTW I am doing a full deployment, not just an application. This problem also occurs if I try to deploy the SYSPROG app so it is nothing to do with our application.

 

The source for RDKEXTRACTENTITIES seems to be out-of-date since if you recompile it you get a problem with the common declaration in the GASGAUGE stproc. Where can I get up-to-date source for debugging purposes?

 

Regards,

Andrew Gebbett

CSSP UK 

I've been looking at that same code for a similar, if not the same problem. Only difference was that I did not get the compilation errors. I'm looking at RDKEXTRACTENTITIES and RDKEXTPREPAPPLICATION, but I had to hack the latter some since it would not compile.

I'm starting to think is a problem with a status call not being reset.

[email protected]

Sprezzatura, Inc.

]run RLIST "LIST SYSREPOS JUSTLEN 50 WITH TYPEID EQ 'IMAGE' AND WITH SUB_KEY EQ ''",1

]You should see some entities, either delete them from your repository, mark

]them as unpublishable, or fill in a subkey (if it exists) and try to

]deploy again. 

This solved the problem by identifying SYSPROG*IMAGE*ICO*OIKB as the problem entity which I have now set to non-publishable.

 

Thanks for the help in solving this problem. We use deployment quite a lot so it was causing us quite a lot of trouble!

Regards,

Andrew Gebbett

CSSP UK 

View this thread on the forum...