× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Rick, let me introduce you to user space freedom. It looks as if you are concerned about the layout of user spaces as used by list APIs. If you are using the user space yourself, with no API call, there is no generic header as you describe, so you can put data anywhere you want.

If you are using a list API and want to preserve the generic header stuff, you need to extract the offset to user data and add that to 1.

User spaces are just big unformatted places to put data - you (or an API) are in control of what goes where.

You can verify this with the DMPOBJ command. Create a new user space, initialized with x'00' of size 1000 (it'll actually be 4096, since that's the size of a singe "page" on DASD). Execute DMPOBJ against it - you will see a section called SPACE ATTRIBUTES-, then a section called SPACE-, which is where the stuff goes when you use the QUSCHGUS program. Note that it starts with 000000, which is an offset equivalent of starting position. C and RPGLE can use pointers to a user space and have a better time with offsets. This is, in fact, more efficient than the API you are using. In RPG use the QUSPTRUS API (?) to assign the address of the user space to a pointer variable. Or use the MI library function RSLVSP (resolve system pointer). There is no risk with this - it is one of the functions that IBM makes available to hihg-level languages, and it is read-only as far as the pointer is concerned. Syntax, I think, could be

rslvsp(intenger: char(31): char(31): integer)

The first argument is for the object type, which is x'1934' for a user space. The last argument is for authority requested, which, for *ALL is x'ff1c'.

The 2nd and 3rd arguments are object name and library, resp. Each is a 31-character variable, with the names starting in position 1, padded with blanks, and ending with x'00' in position 31. Some info from the list is at <http://archive.midrange.com/mi400/200007/msg00069.html>

The program returns a pointer to the user space (or any other object type - can be used for calling programs by address) The technique is used to have a "variable" up to 16meg in size in RPG. And since user spaces can be set to auto-extend, it is effectively a variable length buffer.

HTH
Vern

At 04:17 PM 12/22/2003 +1100, you wrote:
List,

I am using the Change User Space (QUSCHGUS) API to allow me to pass some data
between programs (max 65K, DataQueues are not an option).
The data is returned in the User Area of the General Header Section.
This is only 64 characters. A field larger than that will over-write the Header
values following this field.


Is this normal behaviour ?  Am I missing something ?
I expected the data to be from the offset of data.

Oh, I did RTFM, Google and Midrange.com archive search before posting ...

Any help appreciated.

                   EVAL      US_GenLength = 140
                   EVAL      US_StartPos = 1
* Retrieve values from the user space - Header record returned
                   CALL      'QUSRTVUS'
                   PARM                    US_SpaceName
                   PARM                    US_StartPos
                   PARM                    US_GenLength
                   PARM                    GHS_Header
                   PARM                    EC_ErrorCode
* Set data offset for User Space change
                   EVAL      US_StartPos   = GHS_OffsData + 1
                   EVAL      US_LengthData = Fx - 1
                   EVAL      US_Data = %subst(WRK_LargeFld:1:Fx-1)
                   EVAL      US_FrcAuxStg  = *ZERO
* Make sure that any exception is returned to the program
                   EVAL      EC_ErrorCode = *BLANKS
                   EVAL      EC_BytesProv = 16
* Call the Change User Space API
                   CALL      'QUSCHGUS'
                   PARM                    US_SpaceName
                   PARM                    US_StartPos
                   PARM                    US_LengthData
                   PARM                    US_Data
                   PARM                    US_FrcAuxStg
                   PARM                    EC_ErrorCode

Regards,

Rick Renkema
iSeries Developer
Mid-Comp International Pty Ltd
Phone : +61 3 9011 8288
Fax : +61 3 9544 9631
Mobile : +61 (0)414 877 483
email : rickr@xxxxxxxxxxxxxx

"All great discoveries are made by mistake"
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.