Jump to content


Photo
- - - - -

Task/Function error


19 replies to this topic

#1 TomWhite

TomWhite

    Member

  • Members
  • PipPip
  • 35 posts

Posted 15 August 2005 - 06:38 PM

We're trying to set up Bus and Task Processing in a Linux environment with windows clients using the latest versions - After much trial and error we've got the task communicating with the kernel at least. The problem we have now is it returns an error saying the function execution failed - how descriptive. We are able to run the function directly in VIP logged on as the same user the task is using - ruling out any type of security issues - does anyone have any experience with tasks and debugging these types of issues?
Thanks in advance for your responses.

#2 Rick Young

Rick Young

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 16 August 2005 - 03:33 PM

Debugging this, is a right royal P.I.T.A.


Some things to check:
/var/adm/syslog/syslog.log (or equivalent file for your 'nix flavour)
/etc/rc.log (or equiv...)

[Pro4 Bus] section in .ini - P4EVENTREPORTLEVEL=4 to try and aid in reporting.

TRACEGEN and TRACEDAEMON vars - I honestly can't remember there purpose, I'd have to re-read the manual for those.

Hope this helps in some small way

-Rick

#3 TomWhite

TomWhite

    Member

  • Members
  • PipPip
  • 35 posts

Posted 16 August 2005 - 03:36 PM

We've tracked this down to a - Cannot successfully open print file error - output is defined to go to 'API:OUTFMT=D' in $SPOOL. Is there somewhere else to check settings for this?

Thanks.

#4 Rick Young

Rick Young

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 16 August 2005 - 03:47 PM

I chose to only use the API:OUTFMT=XE for outputting XML. For "real reports" (i.e. stuff to print on physical printers), I use @RPTOPT in either the function immediately preceding the R/GR function or in the Logic In of the R function.

I also found that SET_RPTOPT seemed to be unreliable within Bus & Tasks environment, but the same function within the normal environment, it worked fine.

Edited by Rick Young, 16 August 2005 - 03:50 PM.


#5 TomWhite

TomWhite

    Member

  • Members
  • PipPip
  • 35 posts

Posted 16 August 2005 - 04:19 PM

This function is being called solely from a task so the output option is hard coded - there's no need to set it up through @RPTOPT - I was just wondering if there was anywhere you have to set up something specific for tasks other than $SPOOL.

#6 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 16 August 2005 - 04:49 PM

Tom,

I can't answer the bus and task side of this. However, CANNOT SUCCESSFULLY OPEN PRINT FILE is almost always a permissions error.

hth,

Joseph

#7 TomWhite

TomWhite

    Member

  • Members
  • PipPip
  • 35 posts

Posted 16 August 2005 - 06:05 PM

Not sure what/where permissions would need to be set - it's my understanding that this should just return a CSV to the caller - not create a file/print job. Right now we're just using a VB task tester to call it.

#8 Rick Young

Rick Young

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 16 August 2005 - 06:23 PM

Regardless of the fact that it ought not be "necessary"...try:
Example 3 from B&T manual in the DSL section. To use @RPTOPT. Set the device type (first field) to 10, and set the report device name to “API:OUTFMT=D” in the second field:
@RPTOPT = “10,API:OUTFMT=D,,,,,,Y,Y,Y”
The last three “Y”s are used to suppress the page header, the standard first line, and the initial page
eject, as those are not normally required. You can specify them if you wish.

#9 TomWhite

TomWhite

    Member

  • Members
  • PipPip
  • 35 posts

Posted 16 August 2005 - 08:17 PM

Rick - I tried setting @RPTOPT in logic in as this report is the only function called from the task - the results were the same :(

#10 Guest_Guest Rick_*

Guest_Guest Rick_*
  • Guests

Posted 16 August 2005 - 11:22 PM

Only other thing that I can think of suggesting, just to pin down the issue to purely ProIV as opposed to any other outside influence, try using p4task. Although I can't remember the specific circumstances, and I did not write the "windows side" apps - I do recall that when some of the API calls were "not quite made correctly" (there was something do to with multiple opens/closes), odd results happened.


I've found p4task a great tool for pinning down such things.

Although I've never struck your problem (where you are obviously producing printer output from a report), I encountered the opposite (where what should have been sent to a printer, instead got XML'd back out to the API).

No matter how illogical, have you tried creating basically a "dummy" U function for the Task to call, which in turn calls the R function?

Out of ideas :(

-Rick

#11 TomWhite

TomWhite

    Member

  • Members
  • PipPip
  • 35 posts

Posted 17 August 2005 - 11:55 AM

Thanks Rick - but the 'dummy' update calling the report meets with the same results. You're right, it's definitely a report output issue - we've been successful with updates returning parameters. If anyone has any suggestions they would be most welcome.

Thanks in advance.

#12 Guest_Guest Rick_*

Guest_Guest Rick_*
  • Guests

Posted 17 August 2005 - 12:54 PM

Oh - only other thing I forgot to check was the version. Memory fails me (once again...) as to the specific issues, but we had some with the prior release (I think it was 2.10 of v5.5) - running now on 4.11 of v5.5.


-Rick

#13 TomWhite

TomWhite

    Member

  • Members
  • PipPip
  • 35 posts

Posted 17 August 2005 - 01:05 PM

We are also on 4.11 of v5.5 - Tom

#14 Mike Schoen

Mike Schoen

    Expert

  • Members
  • PipPipPipPip
  • 198 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 17 August 2005 - 04:01 PM

Tom,

I dont know if this helps or not, but I have seen non bus/task functions give the error "cannot successfully open print file" when the report generates no data, ie print for an empty select range etc.
Is it possible that you are not getting any output at all?

Mike

#15 Guest_Guest_*

Guest_Guest_*
  • Guests

Posted 17 August 2005 - 04:12 PM

Mike - I've been able to successfully run these reports outside of tasks by changing the output options so I don't think that's it, but thanks for the suggestion.



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users