benbotektips
MIS
It's ridiculous that the generated pdf's to be read thru IWR have those long generated names - like it'd be rocket science to pull the username from the report, it's a one-to-one relationship for each userclass anyway! It's not 'simply an inconvenience since it's invisible to the userr anyway'; what about the very real case when you run a massive burst on a huge list of user classes, and some classes don't work when you run them, even though the burst succeeded? In my case, this happens with a detail transaction report, bursted to 160 user classes, 2 hours to burst!
Fortunately, there's a trick, to locate which insanely-stringed pdf (ex. 3ee4rxs67fdg) belongs to which user class, which is useful just by itself, in case you wnat to minorly adjust some user classes, but extemely moreso to save a 2 hour burst for the sake of a couple of classes.
Let's say there's user class 'managers', under them 'sales', 'technical', etc. Under 'technical', there's a userclass 'tweetybird'. After what appears to be a successful burst, u logon to the intranet with userclass 'managers' - and it shows all sub-managers, in synch with the catalog profiles. U then logon as 'technical', and see all the technical managers, including the data for tweetybird (which makes sense, since tweetybird is a sub-class of technical managers). But then when u logon as tweetybird, nothing . Oh yes, this happens, not often, but too often to be called 'rare'. So, we have to do 2 things: run the report for only tweetybird's data, and somehow propagate this to the rite pdf, to save the trouble of rebursting for that one bird.
Step one, run the client version of the report, the one which was published to IWR, logging on as 'tweetybird. This brings all data for tweetybird only, assuming the catalog filters are set up rite. Then simply save as a pdf, in the same directory where the other generated pdf's are, but a different name . So, what we've done is 'manually' rebursted to this one user class which failed.
Next, logon to report admin, and find the reportid number for the report. This will be on the 'general' tab, rite under report name. Remote connect to the server IWR runs on, either pcanywhere or win2000 remote connect. In here, there's a command we need to cross-reference reports with the pdf's generated from them. Run the command prompt (screen that loox like DOS), go to the ...\program files\cognos\cer1\bin directory, and run the following:
iwrxname -o name of output file that will be generated with names of user classes -r report number gotten from report admin
ex.
iwrxname -o rname.txt -r 158
You get an output file called rname.txt, in the same ...\bin directory, containing a list of pdf files per user class for the last bursted run of reportid 158.
<WHEW!> I know, so far a pain the cognos. It's almost over.
Now, go down the list, reading the user classes, until you get to the section where tweetybird has his report profile spelld out, including the stupid generated pdf name. Carefully go to the output folder that has the generated pdf's, and delete that named one (double check by running it, and seeing it come back empty), then rename the pdf u put there before to the stupid generated name. What we've done is a manual reburst of one specific class, save the report for the needed user class as a pdf, located which stupid generated pdf to be replaced, deleted the non-working pdf, and rename the newly-generated one to the old name. Somewhere, the index link will work, when u logon to the IWR intranet as the user 'tweetybird', it will work.
This worx for IWR 6.0, Cognos sez it will for 7.0, but it's more complicated (!!!),so I'd love to see it. For further clarification, or if I didn't spell out something exactly rite, look up 'iwrxname' in cognos documentation.
Fortunately, there's a trick, to locate which insanely-stringed pdf (ex. 3ee4rxs67fdg) belongs to which user class, which is useful just by itself, in case you wnat to minorly adjust some user classes, but extemely moreso to save a 2 hour burst for the sake of a couple of classes.
Let's say there's user class 'managers', under them 'sales', 'technical', etc. Under 'technical', there's a userclass 'tweetybird'. After what appears to be a successful burst, u logon to the intranet with userclass 'managers' - and it shows all sub-managers, in synch with the catalog profiles. U then logon as 'technical', and see all the technical managers, including the data for tweetybird (which makes sense, since tweetybird is a sub-class of technical managers). But then when u logon as tweetybird, nothing . Oh yes, this happens, not often, but too often to be called 'rare'. So, we have to do 2 things: run the report for only tweetybird's data, and somehow propagate this to the rite pdf, to save the trouble of rebursting for that one bird.
Step one, run the client version of the report, the one which was published to IWR, logging on as 'tweetybird. This brings all data for tweetybird only, assuming the catalog filters are set up rite. Then simply save as a pdf, in the same directory where the other generated pdf's are, but a different name . So, what we've done is 'manually' rebursted to this one user class which failed.
Next, logon to report admin, and find the reportid number for the report. This will be on the 'general' tab, rite under report name. Remote connect to the server IWR runs on, either pcanywhere or win2000 remote connect. In here, there's a command we need to cross-reference reports with the pdf's generated from them. Run the command prompt (screen that loox like DOS), go to the ...\program files\cognos\cer1\bin directory, and run the following:
iwrxname -o name of output file that will be generated with names of user classes -r report number gotten from report admin
ex.
iwrxname -o rname.txt -r 158
You get an output file called rname.txt, in the same ...\bin directory, containing a list of pdf files per user class for the last bursted run of reportid 158.
<WHEW!> I know, so far a pain the cognos. It's almost over.
Now, go down the list, reading the user classes, until you get to the section where tweetybird has his report profile spelld out, including the stupid generated pdf name. Carefully go to the output folder that has the generated pdf's, and delete that named one (double check by running it, and seeing it come back empty), then rename the pdf u put there before to the stupid generated name. What we've done is a manual reburst of one specific class, save the report for the needed user class as a pdf, located which stupid generated pdf to be replaced, deleted the non-working pdf, and rename the newly-generated one to the old name. Somewhere, the index link will work, when u logon to the IWR intranet as the user 'tweetybird', it will work.
This worx for IWR 6.0, Cognos sez it will for 7.0, but it's more complicated (!!!),so I'd love to see it. For further clarification, or if I didn't spell out something exactly rite, look up 'iwrxname' in cognos documentation.