RE: QRCVDTAQ

["Cassidy, Alan" <CassidyA@xxxxxxxxxx>]

Since we're bearing our souls on this one :-), for reasons already given, in 
general, I think that data queues have been scandalously underutilized in most 
of the RPG shops I've worked in. Especially in times past, when response times 
were so pitifully slow for programs heavy in I/O and interactive. 


> > Why use Unix when there is .NET?

> Maybe because the unix API's are pretty much standardized across many
platforms and have existed for decades, while .NET is not on multiple
platforms and have only existed for a handful of years.  AFAIK, there is
no .NET api built into the iSeries yet.

..>>> One of the RPG programmers here is a dot-Net wannabe, and he showed me a 
bunch of .NET classes you can pick up in OpsNav or Client Access (forget which, 
or both). But he said a whole bunch of them have problems. 

...Also, if .NET is worth its salt, it will also serve up for the Unix API's. 
Otherwise MS is missing zillions of established systems who aren't going to 
jump to an MS server just like that..

> > The background job transaction does not run under the authority of
the user who initiated the transaction.  There are ways to get around
this but it is work and does not solve all the problems.

> Depends on how it's implemented and what it does.  Any client / server
system should have some form of security and authentication mechanism
built in.

..>> That's what I did with my application, worked fine, and I built in the use 
of the senderID as well, which provides the data you need for security checks. 

--Alan