les

It also means to be abandoned or left isolated as in :

A van carrying red paint, collided with another van carrying blue paint and
several motorists were left marooned.

:-)

Les

david frank

As a IBM rep has said, ALL their current compilers support ONLY ASCII as the
native text,
which is what Fortran supports.
Furthermore, like always my challenge only addresses Windows PL/I
capabilities.

I believe you got involved when a similar challenge was for a PL/I TRIM
function to be written, yes/no?
(only Windows PL/I has such a function?)..

A PL/I function declaration cant declare a string output length determined
dynamically by input string length,
in fact mainframe PL/I hardly supports at all, isnt that true?

function User_String_Function(s1) result (s2)
character(*) :: s1
character(len(s1)) :: s2 ! <- cant do this even in Windows PL/I

re: PL/I TRANSLATE

I will have a look at adding a TRANSLATE function to my strings module to
support code conversion
(the 0:255 problem)

note: it was Robin Vowels who again cross-posted a PL/I topic to
comp.lang.fortran

david frank

I replied in comp.lang.pl1 that it meant that the hard-core bakers-dozen of
IBM syncophants still posting has had their pristine IBM-BLUE TEAM PL/I
t-shirts discolored in the last decade by the CRAP they spread in the
newsgroup.

But one of the replies provided a better definition, which is: IBM has
"marooned" PL/I programmers with cutbacks in
platforms supported vs. that supported by their C++ Fortran compilers thus
I have adopted that definition,
marooneds shortens to MAROONS
Does it also question their IQ levels, well who would hire one of them
today?

Meanwhile IBM moves on with a Fortran (claiming some F2003 capabilities) for
Linux
But has NO plans for a PL/I for Linux, and has stopped its PL/I quarterly
newsletter 5 years ago.

robin

|"robin" <robin_v@bigpond.com> wrote in message |news:HFXUe.30311$FA3.12756@news-server.bigpond.net.au...
|> David Frank wrote in message ...
|>>
|>> However I assert that PL/I syntax cant be used to create a Upper
|>> function, |
|> PL/I has an UPPERCASE function, as well as LOWERCASE.
|>
|> As well, anyone can write one,
|
|Well anyone aint going to write one, are they?

They wouldn't bother, because the function is:
1. convenient;
2. portable;
3. about 10 times faster than your ******** loop Fortran code; and what's more, 4. it works.
|> but why would you?
|
|To prove your FAQ assertion that PL/I syntax "has more power than Fortran"
|of course.

Well, you've just proved the opposite, haven't you.

A simple function to do the job.

william m. klein

If your concern (as if you actually had one) was for IBM providing the UPPERCASE
and LOWERCASE "BIF's" for Windows PL/I, then please see:
http://publibfi.boulder.ibm.com/epubs/pdf/ibm3lr20.pdf

which is the Language Refererence (for among others) for:

WSED PL/I for Windows

Then look at page 440 for LOWERCASE
and
Page 495 for UPPERCASE

I believe (but won't swear to it) that there actuallyhas been one or more
releases after this one, but this just shows that these built-in functions have
been available for Windows PL/I (from IBM) since 2003 (the copyright for that
manual)

Of course, it is interesting that you "CAN'T" challenges now ONLY apply to PL/I
for Windows (from IBM). You really do need to make that clearer in the future.

As far as EBCDIC goes, you may want to check out:
http://www-1.ibm.com/support/docview.wss?uid=swg27005323&aid=1

and start reading at page 35 where it says (in part),

The workstation compilers support options that instruct the operating system to
treat data and floating-point operations the same way that the mainframe does.
There are suboptions of the DEFAULT compile-time option that you should specify
for all mainframe applications that might need to be changed when moving code to
the workstation:
DEFAULT(EBCDIC) instead of ASCII
DEFAULT(HEXADEC) instead of IEEE
DEFAULT(E(HEXADEC)) instead of DFT(E(IEEE))
DEFAULT (NONNATIVE) instead of NATIVE
DEFAULT (NONNATIVEADDR) instead of NATIVEADDR
For more information on these compile-time options, see "DEFAULT" on page 46."


--
Bill Klein
wmklein <at> ix.netcom.com

robin

|"James J. Weinkam" <jjw@cs.sfu.ca> wrote in message |news:W%0Ve.269044$on1.102625@clgrps13...
|>
|> As Robin has said, recent versions of PL/I have UPPERCASE and LOWERCASE
|> built in functions which work correctly irrespective of the character code
|> in use. Your code will fail in EBCDIC. All version of PL/I have the
|> TRANSLATE built in function. UPPERCASE and LOWERCASE are just special
|> cases of TRANSLATE which is also independent of character code.
|>
|> Although it would be foolish to do so, it would be easy to write code
|> equivalent to yours using RANK and BYTE. Only a masochist would do so,
|> since the result would be slower and non portable.
|
|As a IBM rep has said, ALL their current compilers support ONLY ASCII as the
|native text,
|which is what Fortran supports.
|Furthermore, like always my challenge only addresses Windows PL/I
|capabilities.

Windows PL/I supports EBCDIC as well as ASCII,
and 16-bit characters and GRAPHIC.
So does Enterprise PL/I (z/OS).
Why don't you read the manual?

|I believe you got involved when a similar challenge was for a PL/I TRIM
|function to be written, yes/no?
|(only Windows PL/I has such a function?)..

TRIM is available at least in Enterprise PL/I, Windows VA PL/I, and PL/I for OS/2.

|A PL/I function declaration cant declare a string output length determined
|dynamically by input string length,
|in fact mainframe PL/I hardly supports at all, isnt that true?

Why don't you read the manual?
A PL/I function can return a character string whose
current length depends on an input string length or
anything else.

|function User_String_Function(s1) result (s2)
|character(*) :: s1
|character(len(s1)) :: s2 ! <- cant do this even in Windows PL/I

Can so -
declare s2 char (length(s1));
in all versions of PL/I.
You really need to read the manual.

|note: it was Robin Vowels who again cross-posted a PL/I topic to
|comp.lang.fortran

It was a Fortran topic.

tim challenger

How do they ever manage across the road on the mainframe, I wonder?
--
Tim C.

dick hendrickson

I'm curious about the non portable part. It's easy to write
a standard conforming portable Fortran uppercase or
lowercase function. Is the PL/I version non portable
because you'd attempt to mimic Dave's Fortran coding style,
or is there an inherent reason why character conversions
are nonportable. I haven't seen Dave's Fortran functions
(at least not in this round ). But, he often writes
functions that are special cased to one particular compiler
rather than use the natural Fortran character operations.
Like I said, I'm curious if that's what makes the PL/I
version non portable.

**** Hendrickson

david frank

As usual you will blather for dozens of lines, but wont commit yourself to
posting a actual function
that shud take half-a-dozen statements, why is that ALWAYS the case?

No-one will backup your assertion that a RETURNS statement can be declared
as you HINT it can
because it cant,
You really need to read the manual..

david frank

http://home.earthlink.net/~dave_gemini/pli_cant.faq

has always asserted its "CANTS" are aimed at IBM's Windows PL/I