Remove an object

OK, so I have 1 Workarea. In there testing, I somehow submitted a templating manifest file. So if I generate a new template I get preview.removemanifest.error.msg when making the 1st preview (I have this in iw.cfg preview_history_limit=5) I have a 0 length file zz_tst_aknipp_0_manifest

Y:\default\main\USAirways\Vacations\WORKAREA\Content>iwattrib zz_tst_aknipp_0_manifest objid
0x0000100846267d7340007812

Since there is a file name name (but not in the staging area) I cannot preview. I also cannot find out how to delete this file (because I have deleted and submitted but it still fails).

Tips/Pointers/RTFMs appreciated.

Andy

Without witnessing the problem and poking around - the only thing I can think of is delete the workarea and create a new one and see if the problem persists.

gzevin

Andy,

have you tried to check for stale locks? This is the first thing I always do when something like that comes up.

iwstalelocks is a support-supplied script

Andy -
We're having the exact same problem. Didja come up with anything? I too tried submitting the delete, but it did not do anything. Once the limit is reached and it cycles back to the zero, you get the preview.removemanifest.error (as you know).

The problem with creating a new workarea for the branch is that it'll still have the same STAGING area, at least as far as I can tell. I guess I'll try it though.
[EDIT: I guess I was correct -- using a new workarea didn't help because that file still exists in staging]

I've got a case open (or trying to reopen a case) with support. I will share anything I find.

Bjorn

I have a support case open, will let you know after GearUp

Andy -
We're having the exact same problem. Didja come up with anything? I too tried submitting the delete, but it did not do anything. Once the limit is reached and it cycles back to the zero, you get the preview.removemanifest.error (as you know).

The problem with creating a new workarea for the branch is that it'll still have the same STAGING area, at least as far as I can tell. I guess I'll try it though.
[EDIT: I guess I was correct -- using a new workarea didn't help because that file still exists in staging]

I've got a case open (or trying to reopen a case) with support. I will share anything I find.

Bjorn

OK, so there is a FR 70425 that you should sign you company up with. Why it is a FR when it is obviously a defect I have no idea.

The basic issue is that a zz_manifest get submitted (usually through iwsubmit) and then cannot be reused if you delete it.

The FR is that templating should just go to the next # in the list.

There *reportedly* was a jar patch (formspub.jar) made for some customer. I have not been able to acquire it.

OK, so there is a FR 70425 that you should sign you company up with. Why it is a FR when it is obviously a defect I have no idea.

The basic issue is that a zz_manifest get submitted (usually through iwsubmit) and then cannot be reused if you delete it.

The FR is that templating should just go to the next # in the list.

There *reportedly* was a jar patch (formspub.jar) made for some customer. I have not been able to acquire it.

Have you gotten any updates on this?
I think I just managed to run into the same bogosity (the zz_* files aren't listed in the autoprivate.cfg.example file, so they weren't part of the autoprivate.cfg file either - and somehow a manifest got submitted.

Did creating a new workarea file this? Or did you have to create a whole new branch?

None of the above. There is a FEATURE REQUEST (70425) that says if TST cannot write to a manifest, is should go to the next one. Why this is a FR and not a bug is beyond freaking me.

I boosted the # of files to 500 and have a job delete them.

Very poor solution. I doubt a new WA will work, new branch probably would but that is a heavy operation.

I was hoping this FR would be available in the new SP but it was not.

FYI, there is a "black patch" available for this, however support will not provide it. If we talk about this enough, then maybe IWOV will fix it.

Andy

Gentlemen -

We're in the same boat, but I'm pretty frustrated to see this as a FR. We have far too much content in far too many branches to up the amount of manifest files and then delete them in a job (as Andy is doing). Besides, the product isn't working as it should. I'm not sure why that requires a feature request to fix.

Man - I'm frustrated right now.

For what it's worth, could we change the preview directory to some temp directory (which solves the current conflict problems) and then use autoprivate.cfg to prevent the manifest files from being submitted if the CLT is used (which would solve the problem going forward)? Haven't thought it through, but just wanted to throw out the idea and see what anyone else thinks. Of course, if you make that change, it will take place in all your workareas which would still be a pain or less than optimal if you have a lot of 'em.

For what it's worth, could we change the preview directory to some temp directory (which solves the current conflict problems) and then use autoprivate.cfg to prevent the manifest files from being submitted if the CLT is used (which would solve the problem going forward)? Haven't thought it through, but just wanted to throw out the idea and see what anyone else thinks. Of course, if you make that change, it will take place in all your workareas which would still be a pain or less than optimal if you have a lot of 'em.

I did open a case with Support (and the support person I spoke to, also didn't understand why it was listed as an FR). They indicated that it is supposed to be fixed in SP1 - which I believe is due out around the end of the month [?], and they did say that there was a "black patch" floating around, but he wasn't sure exactly where (and if he finds it he said he'd send it / a pointer to me)

In the meantime I've adjusted my autoprivate.cfg to include a pattern for

((zz_x)(3)(0))

and have bumped the preview_history_limit value (which seems to work)

If I hear back anything more from Support I'll try to update the thread.

I guess mine must be pretty close as well.

((zz_tst_)(7)(0)) [TeamSite preview]

I *think* they all start with zz_tst_

The fact that the sample autoprivate.cfg does not include these is also another boneheaded move.

I guess mine must be pretty close as well.

((zz_tst_)(7)(0)) [TeamSite preview]

I *think* they all start with zz_tst_

The fact that the sample autoprivate.cfg does not include these is also another boneheaded move.

Yes, and I mentioned that -- but more to the point -- the fact that TS 6.7.1 isn't doing it automatically, internally - like all previous versions of TS - is the actual source of the problem (think about it, you never needed an autoprivate.cfg file in place to be able to do preview before ...

Yes, and I mentioned that -- but more to the point -- the fact that TS 6.7.1 isn't doing it automatically, internally - like all previous versions of TS - is the actual source of the problem (think about it, you never needed an autoprivate.cfg file in place to be able to do preview before ...

Hmm, I guess that should be another Feature Request.

Funny how IWOV is silent on this thread.

Hmm, I guess that should be another Feature Request.

Funny how IWOV is silent on this thread.

My Support contact (a reputable one) is trying to find out if they can get an official patch released for this in the short-term, and ensure that the fix gets into SP1 for the long-term.

Once they have a real patch (or SP1 gets released) then you'll probably hear from them ;-)

My Support contact (a reputable one) is trying to find out if they can get an official patch released for this in the short-term, and ensure that the fix gets into SP1 for the long-term.

Once they have a real patch (or SP1 gets released) then you'll probably hear from them ;-)

We have heard from support that it will be fixed in SP1. Late July-ish?

We have heard from support that it will be fixed in SP1. Late July-ish?

I'll let you know in a bit. The SP1 Beta just was released and I am downloading it.

Andy