× 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.



What Charles and I are trying to say, is that if you DON'T code CVTOPT(*VARLEN) in your H spec, nor on your CRT* command, RPG will handle all this for you very nicely.

1) As below, your field will occupy 9002 bytes of memory, but the compiler handles all that for you.

2) Your use of TRIM() is dubious. If you are trying to left-adjust the field, then your usage is OK. But if instead you are only tyring to lop off the characters after the last nonblank, in this instance TRIM() is unnecessary since you are handling the Length attribute.

3) Without CVTOPT(*VARLEN), your DS goes away and the assignment becomes very simple:
myVarLenField = %TrimR(myBigField)

Methinks you are trying too hard.

As Charles implied, the storage for the variable is not initialized beyond the stored field length. Whatever value or garbage might have been in that DS before the READ will not be changed.

Also, the field termination is not by NULL character as you seem to expect. The field length is indicated solely by the length field. The fact that you found a NULL somewhere in that data is coincidence.

First, your 8998 field should be 9000 instead; the entire field in
RPG/COBOL consumes 9002 bytes, not 9000.

Secondly, when you say you have this data, what is it that's telling
you so? Is this an SQL dump, a view from a HLL program, REXX, or
something else?

"PAPWORTH Paul" <Paul.PAPWORTH@xxxxxxxx> wrote:

I have a file with a zone defined as 9000
VARLEN(100)



In the programme I set this varying length field as follows





D i E DS EXTNAME(Fccin1 )
qualified

D ljZVarLen 5I 0 OverLay(IN1ZPARVAR : 1)

D ljZVarChr 8998 OverLay(IN1ZPARVAR : 3)

// Data

i.ljzvarchr = %trim(zpmess) ;

// Length

i.ljzvarlen = %len(%trim(zpmess)) ;





In ZPMESS I have 'TEST MESSAGE'



Aftre the file write I have



TEST MESSAGE ----

ECEE4DCEECCC444444444444444444444444444444444444444444444444444444000

3523045221750000000000000000000000000000000000000000000000000000000000



Why do I have 5O+ blanks between the end of the data and the first
null
(in yellow)





Thanks in advance







--
This is the RPG programming on the IBM i / System i (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.

--
Sent from my Galaxy tablet phone with with K-9 Mail. Please excuse my
brevity.
--
This is the RPG programming on the IBM i / System i (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.

--
Sent from my Galaxy tablet phone with with K-9 Mail. Please excuse my brevity.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.