Zero suppress zero balance but not leading zeros
RSBAS400
balance but NOT zero suppress leading zeros. By looking at the CRTEDTCDE cmd,
it appears you can. Example:
the number 011100 should read as 011100 on the screen
the number 0 should read as BLANK on the screen.
We already have QEDIT5 thru QEDIT9 defined on out AS/400 and I am not sure if
those cam with OS/400 or someone created them. So I am reluctant to just
delete and re-create a new one. Thanks..
PS..I DO NOT want to change the field to char. or condition an attribute with
an indicator...I already know how to do that..
Ian Stewart
Hi,
They are set up by default I think. In theory, you can change them to suit your
purposes.
In practise, forget it. They're globally defined over the entire machine, making
it the most singularly useless feature I can think of. Which is unfortunate,
really, as I'd really like to be able to use them too ...
-Ian.
--
Ian Stewart
i...@incognito.co.nz
RSBAS400
and NOT display a ZERO balance...
Tim
INTMASK('0 / / ')
ZEROBAL(*NO)
TEXT('Edit a date (suppress zero values)')
This command will do what you want
"RSBAS400" <rsba...@aol.com> wrote in message
news:20000116105440...@ng-cn1.aol.com...
Ian Stewart
> CRTEDTD EDTD(8)
> INTMASK('0 / / ')
> ZEROBAL(*NO)
> TEXT('Edit a date (suppress zero values)')
>
> This command will do what you want
Which still doesn't address the issue that if I write a package which also
uses user-defined edit code "8" for some other purpose, you've got a problem
Thomas
FWIW, IMHO and on the other OTOH, if you are writing a "package", you
obviously shouldn't be using the user-defined edit codes. Use edit words
or other alternatives such as the Edit APIs.
Tom Liotta
In article <3883B83B...@incognito.co.nz>,
--
Tom Liotta
AS/400 systems programmer
Sent via Deja.com http://www.deja.com/
Before you buy.
Ian Stewart
Er ... did you see my earlier post on this topic. Don't worry, I'm not
about to use these things! Just trying to make sure nobody else
inadvertently does either - as it stands I can't see how anyone can use them
without the risk of conflicts. I'd hate to have to fix a system that used
them extensively! It'd be almost as much fun as Y2K ... but not quite!
(Anyone at Rochester know *why* these things were done that way? They seem
to create objects, why can't they be anywhere in the library list as per
most others? Would it be so hard to fix it??? BTW, "but nobody uses them
anyway" isn't a justification; they *would* get used if they could be ...)
-Ian.
Thomas wrote:
--
Ian Stewart
i...@incognito.co.nz
Charles R. Pence
> Thomas:
>
> Er... did you see my earlier post on this topic. Don't worry, I'm not
> about to use these things! Just trying to make sure nobody else
> inadvertently does either - as it stands I can't see how anyone can use
> them without the risk of conflicts. I'd hate to have to fix a system
> that used them extensively! It'd be almost as much fun as Y2K ...
> but not quite!
>
> (Anyone at Rochester know *why* these things were done that way? They
> seem to create objects, why can't they be anywhere in the library list as
> per most others? Would it be so hard to fix it??? BTW, "but nobody uses
> them anyway" isn't a justification; they *would* get used if they could
> be ...)
>
> -Ian.
>
> Thomas wrote:
> > Ian:
> > FWIW, IMHO and on the other OTOH, if you are writing a "package", you
> > obviously shouldn't be using the user-defined edit codes. Use edit words
> > or other alternatives such as the Edit APIs.
> >
> > Tom Liotta
> >
> > > Tim wrote:
> > >
> > > > CRTEDTD EDTD(8)
> > > > INTMASK('0 / / ')
> > > > ZEROBAL(*NO)
> > > > TEXT('Edit a date (suppress zero values)')
> > > >
> > > > This command will do what you want
> > >
> > > Which still doesn't address the issue that if I write a package which
> > > also uses user-defined edit code "8" for some other purpose, you've
> > > got a problem...
> > >
> > > -Ian.
Like the System Reply List, the Edit Descriptions were not taken to the
user's level. I am guessing it was just a poor carry-over from S/38.
For display and printer files I believe there should be no concern to
create the desired edit description and compile, then include the compiled
display file as part of the package. The edit description from the system
where the compile occurred is saved in the compiled object as its derived/
converted edit mask which will be referenced at run-time <ie. it does not
reference, in my experience, the *EDTD on the system where the display
file is used>.
Also <though I've not tested extensively> there should be no reason you
could not effect directly, as either an initialized variable or as storage
in a data area or such, the Edit Mask generated by an Edit Description
that you decide you like -- thus enabling results similar in operation to
a display file, where the mask is part of the delivered package.?.?
By using the API QECCVTEC to convert a previously created QEDIT8, I
can generate an Edit Mask for use in the API QECEDT. It does not
matter that/where I store that mask for later use. Once I have a copy
of the edit mask, I can restore the original *EDTD. The problem I see
with this methodology is that the Type(len,dec) are fairly strict;
except perhaps when the data is addressed by pointer or otherwise can
be given as a substring copy to the latter API.
More specifically for storing a mask:
CRTSAVF QGPL/SAVEDTD
SAVOBJ *ALL QSYS *SAVF *EDTD SAVF(QGPL/SAVEDTD) UPDHST(*NO)
DLTEDTD EDTD(8)
CRTEDTD EDTD(8) INTMASK(' , , , , 0 , ') FRACMASK(' ')
FILLCHAR(*BLANK) CURSYM($) ZEROBAL(*NO) NEGSTS(-) POSSTS('+')
LFTCNS('[USD]') AUT(*USE)
>Call QECCVTEC for:
Given: For a P(10,2) converting EdtCde(8) gives mask of length x/2D:
* . . . + . . . . 1 . . . . + . *...+....1....+.
03AFBAE4E2C4BB03BAE4E2C4BB03B140 ' ®[USD] [USD] £ '
5B035B03B2B2B2B06B03B2B2AAB36B03 '$ $ ¥¥¥^, ¥¥¡·, '
AAAAAAB34B03AAAAAF4E036003 '¡¡¡·. ¡¡®+ - '
>Call QECEDT for:
Given: The value x'00001113355F' as a P(10,2) edited w/ above:
[USD] $11,133.55+
DLTEDTD EDTD(8)
RSTOBJ *ALL QSYS *SAVF *EDTD SAVF(QGPL/SAVEDTD) OPTION(*NEW)
Regards, Chuck
All comments provided "as is" with no warranties of any kind whatsoever.