What is CHAR VARZ ?
aran...@my-deja.com
i saw some definitions in PLI Visualage:
DCL ... CHAR(*) VARZ
Can anyone tell me: what is exactly VARYINGZ comparing to VARYING ?
Can not find the explanation in the IBM manuals,
thanks for any response,
regards, irwan aranya
Sent via Deja.com http://www.deja.com/
Before you buy.
S Comstock
>Hello,
>
>i saw some definitions in PLI Visualage:
>
>DCL ... CHAR(*) VARZ
>
>Can anyone tell me: what is exactly VARYINGZ comparing to VARYING ?
>
>Can not find the explanation in the IBM manuals,
>
VARZ indicates a null-terminated string, for simplifying communications between
PL/I and C programs. Available only in the Visual Age version of PL/I.
Regards,
Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com
email: st...@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA
elder...@my-deja.com
there are different ways to represent varying length character strings
in different programming languages and in different databases
- - -
the usual PL/I 'varying' has an internal representation
(which you, as a programmer, need not be aware of)
of a fixed bin(15) field followed by the characters
this fixed bin(15) has the current length of the character string.
- - -
another method, used by C programmers, since C does not really support
character strings, is to terminate the string with a LOW(1) character.
C uses pointers to process strings, the pointer moves from character
to character (rather like POINTERADD) until it meets the LOW character.
The various C library functions for string handling and printf etc are
aware of this C convention.
- - -
Databases, such as Oracle also used this method, but call it VARCHAR2
(2 rather than Z). Until recently Oracle only suppoted these strings.
It now (Oracle8) has support for normal Varying and fixed length
strings [but PLI programmers using Oracle will have to wait until July
for the Oracle "ProPLI PreComiler" to use these features -
- but that is another story]
- - -
In summary
It does not really matter which you use varying or varyingz
but - varyingz may not contain LOW
but - if you are passing a string to (or receiving it from)
a language which defined it as varyingz, then you must
either use varyingz in PLI or change the other program
to use varing (and if its C, that aint't easy)
In article <8ertmq$rng$1...@nnrp1.deja.com>,
aran...@my-deja.com wrote:
> Hello,
>
> i saw some definitions in PLI Visualage:
>
> DCL ... CHAR(*) VARZ
>
> Can anyone tell me: what is exactly VARYINGZ comparing to VARYING ?
>
> Can not find the explanation in the IBM manuals,
>
robin
> In summary
> It does not really matter which you use varying or varyingz
It does matter, in terms of performance.
In the case of VARYING, the LENGTH built-in function is fast (because
the length is retrieved from storage immediately).
In the case of VARYINGZ, the string must be searched to count the
characters until the terminating character, and thus
LENGTH is slow.
In the case of the mainframe, consider:
If a string must be moved, in the case of VARYING, an MVCL
or EX with MVC may be used, again, because the length is known
in advance.
In the case of VARYING, a loop must be used and a test after each character
is moved results in a much slower operation.
Peter Flass
>
> elder...@my-deja.com wrote:
>
> > In summary
> > It does not really matter which you use varying or varyingz
>
> It does matter, in terms of performance.
>
> In the case of VARYING, the LENGTH built-in function is fast (because
> the length is retrieved from storage immediately).
> In the case of VARYINGZ, the string must be searched to count the
> characters until the terminating character, and thus
> LENGTH is slow.
>
> In the case of the mainframe, consider:
>
> If a string must be moved, in the case of VARYING, an MVCL
> or EX with MVC may be used, again, because the length is known
> in advance.
>
This is why IBM introduced the "string" instructions on the newer
processors. CLST and MVST compare/move strings (like CLCL/MVCL)
until a used-specified "ending-character" is detected. I agree that
PL/I VARYING is much nicer, but the performance penalty isn't so great,
assuming VARZ is supported by any mainframe compilers and that the
compilers use the appropriate instructions.
This is also why Intel has the REPE SCASB, etc instructions. I think
it's a case of a sh*tty feature in C finding its way into firmware. Why
not bring back "record marks"
from the old 1401 days!
elder...@my-deja.com
robin <rob...@bigpond.com> wrote:
> elder...@my-deja.com wrote:
>
> > In summary
> > It does not really matter which you use varying or varyingz
>
> It does matter, in terms of performance.
>
ok - you are right - but does it *really* matter?
if you had to use C - such poor performance would be "acceptable"
it is a problem that you can "buy" your way out of -
- - -
since varyingz cannot contain LOW, I would advise not using it
but if you are linking to a limited language or database
then you may have no choice.
- - -
However I do accept your performance point.
and while I wouldn't try too hard to improve perfomance
(programmers are more expensive than computers)
If there are two equal (equal in programming effort)
ways to do something then use the more efficient
For example READ SET rather than READ INTO
- - -
that's my two (euro) cents worth
Mark Yudkin
> Hello,
>
> i saw some definitions in PLI Visualage:
>
> DCL ... CHAR(*) VARZ
>
> Can anyone tell me: what is exactly VARYINGZ comparing to VARYING ?
Nul-termined string, i.e. string is terminated by an invisible '00'x.
It's main use is in interlanguage communication with C, where strings are
nul-terminated.
> Can not find the explanation in the IBM manuals,
Here's an excerpt from the manual, from the section describing VARYING and
VARYINGZ.
The VARYING and VARYINGZ attributes specify that a variable can have a
length varying from 0 to the declared maximum length. NONVARYING specifies
that a variable always has a length equal to the declared length.
The storage allocated for VARYING strings is 2 bytes longer than the
declared length. The leftmost 2 bytes hold the string's current length.
The storage allocated for a VARYINGZ character string is 1 byte longer than
the declared length. The current length of the string is equal to the number
of bytes before the first '00'x in the storage allocated to it.
The storage allocated for a VARYINGZ GRAPHIC string is 2 bytes longer than
the declared length. The current length of the string is equal to half the
number of bytes before the first '0000'gx in the storage allocated to it.
The VARYINGZ attribute is not allowed with BIT strings.
In the following DECLARE statements, both User and Zuser represent
varying-length character data with a maximum length of 15. However, unlike
User, Zuser is null-terminated. The storage allocated is 17 bytes for User
and 16 bytes for Zuser.
declare User character (15) varying;
declare Zuser character (15) varyingz;
The length for User and Zuser at any time is the length of the data item
assigned to it at that time. You can determine the declared and the current
length by using the MAXLENGTH and LENGTH built-in functions, respectively.
The null terminator held in a VARYINGZ string is not used in
comparisons or assignments, other than to determine the length of the
string. Consequently, although the strings in the following declarations
have the same internal hex representation, they do not compare as being
equal:
declare A char(4) nonvarying init( ('abc' || '00'x) );
declare B char(3) varyingz init( 'abc' );
To the contrary, Z and C in this example do compare as equal:
dcl Z char(3) nonvarying init('abc');
dcl C char(3) varyingz init('abc');
VARYINGZ and NONVARYING are not yet supported on OS PL/I.
The VARYING and VARYINGZ strings can be passed and received as parameters
with * length. They can be passed without a descriptor if they have the
NONASSIGNABLE attribute.
>
> thanks for any response,
> regards, irwan aranya
>
>
aran...@my-deja.com
Clem Clarke
dest[++]=src[++]
type loop were about 20 times slower that a PL/I or Pascal varying string.
I then sat down and wrote some C string handling that operated much like PL/I
string so you could code (in C) statements like:
dcl (x,charvar,30"Var Init");
dcl (y,charfixed,40,"Fixed Init");
...
cpy(x,y); // Var from Fixed
cpy(y,x); // Fixed from Var (blank filled)
(I really must finish the documentation, and make them available)
Cheers,
Clem
robin wrote:
> elder...@my-deja.com wrote:
>
> > In summary
> > It does not really matter which you use varying or varyingz
>
> It does matter, in terms of performance.
>
> In the case of VARYING, the LENGTH built-in function is fast (because
> the length is retrieved from storage immediately).
> In the case of VARYINGZ, the string must be searched to count the
> characters until the terminating character, and thus
> LENGTH is slow.
>
> In the case of the mainframe, consider:
>
> If a string must be moved, in the case of VARYING, an MVCL
> or EX with MVC may be used, again, because the length is known
> in advance.
>
> In the case of VARYING, a loop must be used and a test after each character
>
> is moved results in a much slower operation.
>
,-._|\ Clement V. Clarke - Author Jol, EASYJCL, EASYPANEL, OSCAR, 370TO486
/ Oz \ oscar...@ozemail.com.au, Web:
http://www.ozemail.com.au/~oscarptyltd
\_,--.x/ P.O. Box 475, Toorak, Victoria, AUSTRALIA, 3142.
v Tel (61)-3-9818-8351, Fax (61)-3-9819-2848.
elder...@my-deja.com
yes, you really should document and publish.
It is a pity that you didn't do it years ago.
before the entire C world got hooked on the null terminated string.
the format expected by string handling functions in so many libraries.
- - -
the great advantage of C is its ability to be improved with these
library functions
I wonder just how far you could go to improve C so that it might
approach PLI in terms of ease-of-use and performance ?
- - -
Or am I missing something obvious here ? ;)
In article <3917C139...@ozemail.com.au>,
Clem Clarke <oscar...@ozemail.com.au> wrote:
> Tests I did years ago indicated that copy a "c" string with the
>
> dest[++]=src[++]
>
> type loop were about 20 times slower that a PL/I or Pascal varying
string.
>
> I then sat down and wrote some C string handling that operated much
like PL/I
> string so you could code (in C) statements like:
>
> dcl (x,charvar,30"Var Init");
> dcl (y,charfixed,40,"Fixed Init");
> ...
> cpy(x,y); // Var from Fixed
> cpy(y,x); // Fixed from Var (blank filled)
>
> (I really must finish the documentation, and make them available)
>
> Cheers,
>
> Clem
>
> robin wrote:
>
> > elder...@my-deja.com wrote:
> >
> > > In summary
> > > It does not really matter which you use varying or varyingz
> >
> > It does matter, in terms of performance.
> >
[snip]
Clem Clarke
> yes, you really should document and publish.
> It is a pity that you didn't do it years ago.
> before the entire C world got hooked on the null terminated string.
> the format expected by string handling functions in so many libraries.
>
Well, this was nearly ten years ago now. I fought many battles in the C
Fido area, but got nowhere, and at that time didn't have access to Usenet,
or I would have popped a few messages into the C Ansi group.
I did document it (will email you seperately), and sent it to IBM, MS and
various places. Got nowhere. Now we have bloated slow code, as you say.
> - - -
> the great advantage of C is its ability to be improved with these
> library functions
> I wonder just how far you could go to improve C so that it might
> approach PLI in terms of ease-of-use and performance ?
>
Gosh. I've got another paper I prepared comparing PL/I with C, too. C
can never be as easy to use as PL/I or Pascal in my opinion. Apart from
STRINGS and Strings and strings <smile>, there is no WITH (Pascal) or
based storage, the IF is mucked up, and so on. The only nice things about
C is {}!
I think I have said before it took me about 6 weeks to convert hundreds of
lines of code to Pascal from PL/I, and then *years* to get that to C. Why
did I do it? No PL/I compiler then for OS/2, Dos (flat memory) or Unix.
Was it worth it? We'll see !!
> - - -
> Or am I missing something obvious here ? ;)
>
Cheers,
Clem
elder...@my-deja.com
I received your paper 'Fast & Safe "C" Strings'. Thanks. It is very,
very good.
It is a pity that it was not widely accepted. It is, probably, too
late now.
Many years ago, when hardware development was improving with PCs and
client/server technologies, software development took a great leap
backwards.
Software development had progressed nicely along from Assemblers to
HLLs and then to 4GLs.
Then it all went wrong. The move to PCs and client/servers was sold
as ‘cheap computing’.
That meant cheap, preferably free, compilers. There were plenty of
freeware C compilers.
Performance is not an issue, or if it is, then it is an issue which you
can buy your way out of.
4GLs had been seen as the means to better productivity, Most 4GLs had
become too specialised, depending on CUI (character) screens or
printers with fixed-width fonts.
These 4GLs were rejected, and along with them, any consideration of
programmer productivity.
Security, integrity, recovery, backup-up etc. went the same way.
Witness the latest virus.
The great leap backward was to a world of C and Basic.
Since then a lot has been done to improve these. C has move to C++,
though most of the C++ code I see is really plain C. VB has its screen
painter and there are lots of nice add-ons.
The big advantage that C has is its ability to use the libraries of
macros.
Just like standards, the great thing about these libraries is that
there are so many to choose from.
We have now reached the stage that the tail is wagging the dog.
Rather than language compilers producing efficient code for processors,
processors are now introducing new instructions to, at least partially,
compensate for inefficiencies in a language.
------------------------------------------------------
In article <391A3349...@ozemail.com.au>,