Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
a TRIM function for PL/I
614 views
Skip to first unread message
robin....@gmail.com
Jan 18, 2014, 4:14:11 AM1/18/14
to
David Fran Sun, 05 Dec 2004 18:13:02 GMT
>a TRIM function for PLI
>In a related message thread, its said that a TRIM function is available to
>translate a PL/I string
>to a C string
>similiar to what I posted:
cstring = trim(string) // char(0)
>It was also inferred that one could write their own PLI TRIM function,
> this I would like to see..
....
>--------------------------------
>function trim(s1) result(s2)
>character(*) :: s1
>character(len_trim(s1)) :: s2
>s2 = s1
>end function
---------------------------------
>Anyone able to translate above to PLI?
I think that this was not addressed, so here is an example,
not using PL/I's TRIM function (which is anyway more general
and more useful than Fortran's TRIM function) The Fortran TRIM
function removes only trailing blanks from a string.
trim: procedure (s) returns (character(100) varying);
declare s character (*); declare i fixed binary;
do i = length(s) to 1 by -1;
if substr(s, i, 1) ^= '' then return (substr(s, 1, i));
end;
return ('');
end trim;
[LEN_TRIM is a Fortran intrinsic that returns the length
of the string, ignoring any trailing blanks.]
>a TRIM function for PLI
>In a related message thread, its said that a TRIM function is available to
>translate a PL/I string
>to a C string
>similiar to what I posted:
cstring = trim(string) // char(0)
>It was also inferred that one could write their own PLI TRIM function,
> this I would like to see..
....
>--------------------------------
>function trim(s1) result(s2)
>character(*) :: s1
>character(len_trim(s1)) :: s2
>s2 = s1
>end function
---------------------------------
>Anyone able to translate above to PLI?
I think that this was not addressed, so here is an example,
not using PL/I's TRIM function (which is anyway more general
and more useful than Fortran's TRIM function) The Fortran TRIM
function removes only trailing blanks from a string.
trim: procedure (s) returns (character(100) varying);
declare s character (*); declare i fixed binary;
do i = length(s) to 1 by -1;
if substr(s, i, 1) ^= '' then return (substr(s, 1, i));
end;
return ('');
end trim;
[LEN_TRIM is a Fortran intrinsic that returns the length
of the string, ignoring any trailing blanks.]
Peter J. Seymour
Jan 18, 2014, 4:35:26 AM1/18/14
to
programming standards at an insurance company, I wrote a series of
Builtin-style functions for mainframe PL/I. These were largely covered
in the ANSI PL/I but absent from the Optimiser. They included LEFT,
RIGHT, ASCII, EBCDIC and others. Designing these routines probably took
longer than writing them. Management suggested I might like to do the
same for COBOL, but I never got around to it. It is a useful feature of
PL/I (not exclusive of course) that language feature like routines can
be written in the language (or Assembler for all-out speed if you
preferred).
robin....@gmail.com
Jan 18, 2014, 7:53:37 AM1/18/14
to
On Saturday, January 18, 2014 8:35:26 PM UTC+11, Peter J. Seymour wrote:
> It reminds me that in the 1980s as the person responsible for PL/I programming standards at an insurance company, I wrote a series of Builtin-style functions for mainframe PL/I. These were largely covered in the ANSI PL/I but absent from the Optimiser. They included LEFT, RIGHT, ASCII, EBCDIC and others. Designing these routines probably took longer than writing them. Management suggested I might like to do the same for COBOL, but I never got around to it. It is a useful feature of PL/I (not exclusive of course) that language feature like routines can be written in the language (or Assembler for all-out speed if you preferred).
Indeed. When IBM's PL/I for the PC was released, I wrote almost all
> It reminds me that in the 1980s as the person responsible for PL/I programming standards at an insurance company, I wrote a series of Builtin-style functions for mainframe PL/I. These were largely covered in the ANSI PL/I but absent from the Optimiser. They included LEFT, RIGHT, ASCII, EBCDIC and others. Designing these routines probably took longer than writing them. Management suggested I might like to do the same for COBOL, but I never got around to it. It is a useful feature of PL/I (not exclusive of course) that language feature like routines can be written in the language (or Assembler for all-out speed if you preferred).
the new functions in PL/I, so that anyone using an older compiler
could use the functions as if they were already built-in.
Shmuel Metz
Jan 19, 2014, 8:33:23 PM1/19/14
to
In <SVrCu.24710$h52....@fx15.fr7>, on 01/18/2014
see the utility of ASCII and EBCDIC, given the code page issues; use
of Unicode services is a more flexible way to go.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
at 09:35 AM, "Peter J. Seymour" <n...@pjsey.demon.co.uk> said:
>These were largely covered
>in the ANSI PL/I but absent from the Optimiser.
LEFT, RIGHT and TRIM are present in the Enterprise compiler; I don't
>These were largely covered
>in the ANSI PL/I but absent from the Optimiser.
see the utility of ASCII and EBCDIC, given the code page issues; use
of Unicode services is a more flexible way to go.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
Peter J. Seymour
Jan 20, 2014, 4:33:15 AM1/20/14
to
On 20/01/2014 01:33, Shmuel (Seymour J.) Metz wrote:
> In <SVrCu.24710$h52....@fx15.fr7>, on 01/18/2014
> at 09:35 AM, "Peter J. Seymour" <n...@pjsey.demon.co.uk> said:
>
>> These were largely covered
>> in the ANSI PL/I but absent from the Optimiser.
>
> LEFT, RIGHT and TRIM are present in the Enterprise compiler; I don't
> see the utility of ASCII and EBCDIC, given the code page issues; use
> of Unicode services is a more flexible way to go.
>
Think 1970's era. The compilers cover a lot more today.
> In <SVrCu.24710$h52....@fx15.fr7>, on 01/18/2014
> at 09:35 AM, "Peter J. Seymour" <n...@pjsey.demon.co.uk> said:
>
>> These were largely covered
>> in the ANSI PL/I but absent from the Optimiser.
>
> LEFT, RIGHT and TRIM are present in the Enterprise compiler; I don't
> see the utility of ASCII and EBCDIC, given the code page issues; use
> of Unicode services is a more flexible way to go.
>
Peter J. Seymour
Jan 20, 2014, 4:31:26 AM1/20/14
to
On 20/01/2014 01:33, Shmuel (Seymour J.) Metz wrote:
> In <SVrCu.24710$h52....@fx15.fr7>, on 01/18/2014
> at 09:35 AM, "Peter J. Seymour" <n...@pjsey.demon.co.uk> said:
>
>> These were largely covered
>> in the ANSI PL/I but absent from the Optimiser.
>
> LEFT, RIGHT and TRIM are present in the Enterprise compiler; I don't
> see the utility of ASCII and EBCDIC, given the code page issues; use
> of Unicode services is a more flexible way to go.
>
> at 09:35 AM, "Peter J. Seymour" <n...@pjsey.demon.co.uk> said:
>
>> These were largely covered
>> in the ANSI PL/I but absent from the Optimiser.
>
> LEFT, RIGHT and TRIM are present in the Enterprise compiler; I don't
> see the utility of ASCII and EBCDIC, given the code page issues; use
> of Unicode services is a more flexible way to go.
>
0 new messages