Re: STDIN, STDOUT and pipes

[vhamberg@xxxxxxxxxxx]

Larry you don't use QUSCHGUS to make a user space auto-extensible - there is a different API that manages the attributes. There are several commands out there for creating a user space that do this automatically for you. And the list APIs also do this for you. Bruce Vining's book has one, and I bet you could just google for CRTUSRSPC and find one right quick.

QUSCHGUS) changes the contents of a user space. 
QUSCUSAT) changes the attributes of a user space object. 

I find user spaces easier to deal with when I can just run simple commands - of course, the calls for IFS objects are not terribly difficult, but a margin of some greater complexity. Now if you do need more the 16 MB - you'd want a stream file, as the system adds spaces as needed and manages the addressing. I hope!!

Vern

-------------- Original message -------------- 
From: Larry Ducie <larry_ducie@xxxxxxxxxxx> 

> Hi Simon, 
>
>
>
> There is no real difference between *USRSPC storage and allocated 
> storage (other than the permanence of the *USRSPC). 
>
>
>
>
> If you're using the QUSCHGUS and QUSRTVUS APIs then I can believe 
> they'll be slower than direct pointer access to storage however you 
> can get a pointer to the user space and then it's just as fast as 
> your allocated storage method. 
>
>
>
>
> OK, I need clarification. 
>
> Are we saying I can create a User Space and retrieve the pointer to the 
> beginning of the storage within it, and I can then write directly to that 
> pointer and the storage will expand as I need it to? If that is the case then 
> User Spaces are better than I thought. 
>
> It was my understanding though, that the storage within a User Space would only 
> expand if you used the QUSCHGUS API to write to it. If that is the case then my 
> statement still stands. What possible benefit would a User Space have over a 
> standard data pointer other than the permanence of the data? If all I get is a 
> regular pointer then I there is no point using a User Space. If I wanted the 
> data within a permanent store I'd use a stream file. 
>
>
> f you see significantly slower access times using a pointer to a 
> user space than using a pointer to allocated storage then I'd like to 
> see your test code. 
>
>
>
> Sadly, its no longer my code - it was performed 3 years ago, for another 
> employer, in another hemisphere. But the results were valid. Of course, the 
> access to the User space data was via the APIs, not direct pointer access, and 
> the time for the creation of the User Space was also included in some of the 
> tests. But an overhead is an overhead however you slice it. 
>
> Maybe user spaces have a use as a temporary data storage used by multiple jobs 
> if they are faster than using stream files. 
>
> I am wiling to be convinced. 
>
> Cheers 
>
> Larry Ducie 
>
> _________________________________________________________________ 
> Meet singles near you. Try ninemsn dating now! 
> http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fch 
> annel%2Findex%2Easpx%3Ftrackingid%3D1046247&_t=773166080&_r=WL_TAGLINE&_m=EXT 
> -- 
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list 
> To post a message email: RPG400-L@xxxxxxxxxxxx 
> To subscribe, unsubscribe, or change list options, 
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l 
> or email: RPG400-L-request@xxxxxxxxxxxx 
> Before posting, please take a moment to review the archives 
> at http://archive.midrange.com/rpg400-l.