PL/I and C 
Author Message
 PL/I and C


        Date:         Mon, 22 Jan 1996 16:03:05 -0600

        Hi,

        I am in the process of evaluating the development of Mainframe applications
        using C/370 and PLI under MVS.  The applications being developed include text
        conversions, database maintenance and development, and other I/O intensive
        routines.  I am trying to determine the pros and cons of each language in
        regards to functionality, performance, ease of use, etc...

        Has anyone done a similar type of comparison or have any input on either
        language in regards to their advantages and disadvantages?  Any input would be
        greatly appreciated.

        Thanks.

---This is one of the areas where PL/I excells -- viz, I/O.
It supports a wide range of file access methods, and where
high volume is required, efficient mechanisms for minimizing
data movements during I/O.

   The access methods include sequential and random (i.e. keyed),
and there is provision for dealing with records of differing
sizes as well as, of course, fixed sizes.

   PL/I provides a built-in function for TRANSLATE that can be used
for text conversions.  If you are using foreign languages,
there's provision for double-byte characters.

   For text handling, there are varying-length strings as well as
fixed-length strings.

Robin Vowels



Mon, 10 Aug 1998 03:00:00 GMT  
 PL/I and C
  > I am in the process of evaluating the development of Mainframe
  > applications using C/370 and PLI under MVS.

  For the jobs you mentioned:
    > text conversions, database maintenance and development,
    > and other I/O intensive routines
  PL/I is MUCH better (I am talking about mainframe):

  I. Text Processing.                        
     ---------------
        C does not have so extensive Text Processing built-in functions,
     as PL/I does. Moreover, C has this STUPID limitation - a 'string'
     in C it's a set of bytes with x'00' at the end ! But, we have
     x'00' all over our source data ! It's the same symbol as any other,
     there is nothing special in it. So, I HAD TO write myself ALL
     string functions (sub-string, search,..) using BUFFERS, because I
     was not able to use C 'String' functions.  Obviously, functions
     written by me are not so efficient as Built-in functions,
     so the productivity suffers.
     Also, C does not have Variable Length strings.
     Again, PL/I has BUILT-IN, effective string functions.

  II. Data Structures.                    
      ---------------
          In PL/I, you can consider your source record as a string,
     or as SEVERAL different complex Structures, using Based variables.
     C has it, too,  but with a BIG limitation - if you want to put
     SEVERAL different 'masks' over your buffer, C allows ONLY simple
     variables as items of these structures, not Arrays !

  III. Select/Switch statement.
       -----------------------
       This important part of any program is VERY rudimental and hard
    to use in C - you can use ONLY numbers here:
      switch(my_choice) {                                
        case 0:  
               ....
           break;                                    
        case 1:
               ....
       }

     You can use Enumerations in C but they are still only NUMBERS.
     In PL/I you can use any Expression (!) as a switch, that is, you
     can use Character Strings here, that helps a lot while writing
     Text Processing programs.                    
     ----
     As I heard, C was developed mostly for COMPUTATIONAL tasks - its
     Text Processing options are limited.

  IV. Fixing a problem, debugging. Maintenance.
      ----------------------------------------
   1) C compiler DOESN'T tell me where in my LARGE set of programs
       a failure occurred, unlike PL/I that tells me a Statement Number.
        ( C can do it, but you must buy and use an Additional product -
          de{*filter*} - 'Inspect for C'. But I am afraid, it's too costly in
          a matter of time to run your Production Jobs always with De{*filter*}).
    Imagine, some Production Update failed.  Source file is HUGE.
    Angry Customers call from all over the world.
    This large set of programs IS NOT mine. So, I never saw neither
    Source data, nor Programming Code. I MUST fix the problem in
    a short time.   In C environment I HAVE TO RE-RUN (!!) whole thing
    using de{*filter*}, just to BEGIN my investigation.
    In my opinion, it is ABSOLUTELY unacceptable in Production
    (not Research) environment.
    And the following 2 things support this point:

  2)    C programs are hard to maintain, code is not easy to read.
     So, in the situation I described, where this large set of programs
    is 'old' and was already modified several times by several engineers,
    it is EXTREMELY hard for a person who sees these programs FIRST TIME,
    to investigate and fix a problem, especially in a short time.
    UNLIKE PL/I, where even not a super-programmer can easily read a
    source code.

  3)    Exception(Error) Handling. C does not have it, and as far as I
     know, current version of mainframe C++ does not have it, either.
     What it means...   PL/I not only tells me WHERE a failure occurred
     (see item 1), but it offers me ON ERROR feature, so I know
     2 VERY important things that allow me often DO NOT check HUGE
     source files or HUGE programs and to fix a problem in couple hours:
   a) It tells me THE REASON for failure (I don't need to spend hours
      and re-run entire job with de{*filter*} to find out the reason),
      for example, some I/O problem.
   b) Because I asked so in ON ERROR block, I have, in failed job's
      listing, values of some key variables and, THE BEST, part of
      source file data where error occurred. Without de{*filter*} re-run,
      I can see IMMEDIATELY, that, for example, this source file has
      'dirty' data. So, I DON'T need to investigate a program's CODE at all !
      Again, imagine 40 gigabyte file (!) that you have to re-run
      using de{*filter*} in C environment JUST TO BEGIN your investigation,
      while with PL/I this investigation is already done !

 So, my point is, PL/I is not only BETTER that C, because PL/I code is more
 readable and programs are easy to maintain, but it is just IRREPLACEABLE.

 P.S. If you need more language specific information in regards
      to functionality, performance, etc., then read article by
      Eberhard Sturm ( GUIDE & SHARE Conference, 1994 )
          "Power Vs Adventure - PL/I and C".            WWW address is:
http://www.*-*-*.com/

--



Mon, 10 Aug 1998 03:00:00 GMT  
 PL/I and C

 >In PL/I, you can consider your source record as a string,
 >or as SEVERAL different complex Structures, using Based variables.
 >C has it, too,  but with a BIG limitation - if you want to put
 >SEVERAL different 'masks' over your buffer, C allows ONLY simple
 >variables as items of these structures, not Arrays !

Actually, this is incorrect.

In fact, if I recall correctly a pointer to x is implicitly an array.

---
The above are my own opinions, and not those of my employer.



Tue, 11 Aug 1998 03:00:00 GMT  
 PL/I and C

Quote:



>  >In PL/I, you can consider your source record as a string,
>  >or as SEVERAL different complex Structures, using Based variables.
>  >C has it, too,  but with a BIG limitation - if you want to put
>  >SEVERAL different 'masks' over your buffer, C allows ONLY simple
>  >variables as items of these structures, not Arrays !

> Actually, this is incorrect.

> In fact, if I recall correctly a pointer to x is implicitly an array.

Sorry, you missed my point. If I want to have SEVERAL masks for THE SAME
area of memory, that is have SEVERAL DIFFERENT Structures overlaid my
buffer, C has a feature for this - a Union, where I can have members of
different Nature overlaid the same area of memory, BUT, unlike PL/I, an
Array CAN NOT be a member of a Union. But, it is always a case in our
Text Processing - I want to look at my source record's buffer at some
----
point of time, as at a structure like this:
  1 Patent_Info,
    2 Part_1,
      3 Patent_Number ...
      3 Date_Of_Application...
     ...
    2 Part_5,                              
      3 Opponents,                      or 3 Opponents(10),
        4 Name(10)...                         4 Name...
        4 Address(10)...                      4 Address

In C I CAN NOT do it, so I MUST find some 'work around' and my code's
logic become more complex, less clear, and far from SPECS, because this
structure was given in SPECS. So, next person who will work his FIRST
time with this code, will have trouble.

Regards,
Paul
--



Tue, 11 Aug 1998 03:00:00 GMT  
 PL/I and C

 >Sorry, you missed my point. If I want to have SEVERAL masks for THE SAME
 >area of memory, that is have SEVERAL DIFFERENT Structures overlaid my
 >buffer, C has a feature for this - a Union, where I can have members of
 >different Nature overlaid the same area of memory, BUT, unlike PL/I, an
 >Array CAN NOT be a member of a Union. But, it is always a case in our
 >Text Processing - I want to look at my source record's buffer at some

Huh? Why not? I know of no rule which would preclude having an array in a
union.

... and BTW, you don't need to use a union; you can simply have several
pointers, each containing the same address. Just coerce them with a cast.

   foo *x;
   bar *y;

   y=(bar *) x;

---
The above are my own opinions, and not those of my employer.



Tue, 11 Aug 1998 03:00:00 GMT  
 PL/I and C

|>


|>
|>  >In PL/I, you can consider your source record as a string,
|>  >or as SEVERAL different complex Structures, using Based variables.
|>  >C has it, too,  but with a BIG limitation - if you want to put
|>  >SEVERAL different 'masks' over your buffer, C allows ONLY simple
|>  >variables as items of these structures, not Arrays !
|>
|> Actually, this is incorrect.
|>
|> In fact, if I recall correctly a pointer to x is implicitly an array.

I don't understand this remark at all.  A pointer to x is nothing like
an array.  See the FAQ for a detailed discussion of the relationship
between pointers and arrays.

|Sorry, you missed my point. If I want to have SEVERAL masks for THE SAME
|area of memory, that is have SEVERAL DIFFERENT Structures overlaid my
|buffer, C has a feature for this - a Union, where I can have members of
|different Nature overlaid the same area of memory, BUT, unlike PL/I, an
|Array CAN NOT be a member of a Union. But, it is always a case in our

This is a vicious lie (or at very least, an unfortunate
misconception).  A field in a union can be anything that a field in a
struct can be, incuding a bitfield.

|Text Processing - I want to look at my source record's buffer at some
|----
|point of time, as at a structure like this:
|  1 Patent_Info,
|    2 Part_1,
|      3 Patent_Number ...
|      3 Date_Of_Application...
|     ...
|    2 Part_5,                              
|      3 Opponents,                      or 3 Opponents(10),
|        4 Name(10)...                         4 Name...
|        4 Address(10)...                      4 Address
|                        
|In C I CAN NOT do it, so I MUST find some 'work around' and my code's

union {
  struct {
    char patent_number[10];
    char date_of_application[6];
  } part_1;

  /* ... */

  struct {
    struct {
      char name[80];
      char address[4][80];
    } opponent[10];
  } part_5;

Quote:
} patent_info;

/* ... */

puts(patent_info.part_5.opponent[3].name);

|logic become more complex, less clear, and far from SPECS, because this
|structure was given in SPECS. So, next person who will work his FIRST
|time with this code, will have trouble.
--
                Matthew Saltzman
                Clemson University Math Sciences



Tue, 11 Aug 1998 03:00:00 GMT  
 PL/I and C
-- I am in the process of evaluating the development of Mainframe
applications
--       using C/370 and PLI under MVS.  The applications being developed
include text
--      conversions, database maintenance and development, and other I/O
intensive
---        routines.  I am trying to determine the pros and cons of each
language in
--      regards to functionality, performance, ease of use, etc...

I think all responses to this post have missed an essential point.
Since these are mainframe applications we may reasonably assume that they
are large, and will be around for some time, probably longer than anyone
expects at present. The essential problem with PL/I, despite its many fine
qualities as a language, is that the necessary support personnel are
simply not available, unlike the vast armies of COBOL and C people. Indeed
, all the signs are that their number is likely to diminish in future, and
those that remain will charge the earth if they have any sense.

Bill Rowe



Wed, 12 Aug 1998 03:00:00 GMT  
 PL/I and C

 >VA: Actually, this is incorrect.
 >VA:
 >VA: In fact, if I recall correctly a pointer to x is implicitly an array.
 >
 >Could either of you provide examples of what you mean? I am lost ...

In C, a pointer to foo is practically the same as an array of foo. The only
difference (I believe) is that the array reserves storage, and can't have
its base address modified.

If you have

   foo *x;        /* declare a pointer to foo */
   foo y[10];     /* declare an array of foo */

   x=y;           /* set x to the address of y */

then x[n] and y[n] should have the same address and value. A pointer to foo
can be dereferenced as *x, and this would have a value which is a foo. A
reference such as x[n] is actually equivalent to *(x+n) in C (in C when you
add an integer 'n' to a pointer, it returns the address of the 'n'th
element of that pointed-to type).

---
The above are my own opinions, and not those of my employer.



Thu, 13 Aug 1998 03:00:00 GMT  
 PL/I and C


 >|> Actually, this is incorrect.
 >|>
 >|> In fact, if I recall correctly a pointer to x is implicitly an array.
 >
 >I don't understand this remark at all.  A pointer to x is nothing like
 >an array.  See the FAQ for a detailed discussion of the relationship
 >between pointers and arrays.

This was a comment was made about the capabilities of C.

I was just explaining that in C, if you have a pointer, you also have an
array.

---
The above are my own opinions, and not those of my employer.



Thu, 13 Aug 1998 03:00:00 GMT  
 PL/I and C
Sorry,
I just realized that my postings went to comp.lang.C
in addition to PL/I group. I never intended to discuss C -
there are too many flavors of it. My postings were an answer
to a question posted in PL/I Newsgroup, about
MAINFRAME C vs. PL/I

MAINFRAME C/370 Unions CAN NOT have Arrays as members,
and I surely understand that other C flavors may be
better.

--



Fri, 14 Aug 1998 03:00:00 GMT  
 PL/I and C


        >  > I am in the process of evaluating the development of Mainframe
        >  > applications using C/370 and PLI under MVS.

        >  For the jobs you mentioned:
        >    > text conversions, database maintenance and development,
        >    > and other I/O intensive routines
        >  PL/I is MUCH better (I am talking about mainframe):

        >  I. Text Processing.                        
        >     ---------------
        >        C does not have so extensive Text Processing built-in functions,
        >     as PL/I does. Moreover, C has this STUPID limitation - a 'string'
        >     in C it's a set of bytes with x'00' at the end ! But, we have
        >     x'00' all over our source data ! It's the same symbol as any other,
        >     there is nothing special in it. So, I HAD TO write myself ALL
        >     string functions (sub-string, search,..) using BUFFERS, because I
        >     was not able to use C 'String' functions.  Obviously, functions
        >     written by me are not so efficient as Built-in functions,
        >     so the productivity suffers.
        >     Also, C does not have Variable Length strings.
        >     Again, PL/I has BUILT-IN, effective string functions.

---The basic operations of string-handling are done somewhat
clumsily in C -- catenation is a simple infix operation
in PL/I, but you must use a function in C, and then it
catentates the second operand to the first.  Nothing like
c = d || e;
(And what happens when, in strcat(s1, s2), the sum of the lengths
of s1 and s2 exceeds the declaration for s1?!?!?

---again, for comparison, IF s1 > s2 THEN . . .  becomes
strcmp(s1, s2) . . . which yields neg, 0, or pos . . .
which leads to IF strcmp(s1, s2) > 0 . . .
which is scarcely intuitive [shades of the arcane fortran
arithmetic IF].

   I'd agree with the statement about built-in functions.
PL/I for AIX and OS/2 now have BIFs for searching for specific
characters (SEARCH) either from the right or from the left,
searching for the absence of specififc characters (VERIFY)
from the right or left.

   Furthermore INDEX, SEARCH, SEARCHR, VERIFY and VERIFYR
can start the search at any specified position (the three-
argument versions).

   There are several functions for centering text, & t{*filter*}
given characters from either or both ends of a string.

   And what happens when you actually w*a*n*t a zero byte in your
C character string?




Fri, 14 Aug 1998 03:00:00 GMT  
 PL/I and C

        >-- I am in the process of evaluating the development of Mainframe
        >applications
        >--       using C/370 and PLI under MVS.  The applications being developed
        >include text
        >--      conversions, database maintenance and development, and other I/O
        >intensive
        >---        routines.  I am trying to determine the pros and cons of each
        >language in
        >--      regards to functionality, performance, ease of use, etc...

        >I think all responses to this post have missed an essential point.
        >Since these are mainframe applications we may reasonably assume that they
        >are large, and will be around for some time, probably longer than anyone
        >expects at present. The essential problem with PL/I, despite its many fine
        >qualities as a language, is that the necessary support personnel are
        >simply not available, unlike the vast armies of COBOL and C people.

---You'll find that there are more than enough personnel
available.  There is a very large base skilled in PL/I.

---But you're also saying that someone who is an Ada
programmer cannot do PL/I or that someone who knows
COBOL or FORTRAN cannot do PL/I.  It's simply a
case of supply and demand.  If the demand increases,
so does the supply.

        >Indeed
        >, all the signs are that their number is likely to diminish in future, and
        >those that remain will charge the earth if they have any sense.

---There's no likelihood of that (diminishing in the future)
while PL/I courses are still being run, and while there
are programmers in C, Fortran, COBOL, PL/I, whatever
around . . .

   You'll also find that the PL/I programmer base is
increasing with the availability of PL/I on an increasing
number of platforms -- the largest of which must be on
the PC.

        >Bill Rowe



Fri, 14 Aug 1998 03:00:00 GMT  
 PL/I and C

Quote:



>  >|> In fact, if I recall correctly a pointer to x is implicitly an array.

>  >I don't understand this remark at all.  A pointer to x is nothing like
>  >an array.  See the FAQ for a detailed discussion of the relationship
>  >between pointers and arrays.

> I was just explaining that in C, if you have a pointer, you also have an
> array.

  If I declare char *ptr; in what sense have I gained an array?

  That doesn't make any sense.  An array decays into a pointer to its
first element under certain circumstances* and a pointer of type foo * can
point to an array of foos, but that's about the extent of their
relationship (there are of course void and char pointers, which can point
to [arrays of] any type except functions).  The FAQ has a good discussion of
the difference between arrays and pointers, as does K&R2.

* when the array occurs without []s as an rvalue, as in
int *p, a[10];
p = a;
  when it is operated on by the [] operator (a[6] becomes *(a + 6)),
  and when it is passed as a parameter in a function call.

/**James Robinson***********************            
  "An important goal of almost every graphics program is to draw pictures on
 the screen."    -- Neider, Davis & Woo, _OpenGL_Programming_Guide_, Chapter 10



Fri, 14 Aug 1998 03:00:00 GMT  
 PL/I and C

Quote:
>    And what happens when you actually w*a*n*t a zero byte in your
> C character string?

  Use a standard declaration (char[] or char *) and memcmp(), memcpy(), etc.
Just because the strxxx family of functions expect a nul-terminated
string doesn't mean that C is incapable of dealing with anything else.  I
write C programs that interface with ORACLE7, which doesn't nul-terminate
strings and I haven't run into any trouble yet.  For that matter, you
could declare an array of longs or Pascal-like strings with length bytes
at the beginning and whip up a set of routines to treat those as strings.
That's the advantage of a language which _doesn't_ have string features
built in. :)

  Incidentally, I'm the odd man out in a PL/I shop, so I am not ignorant
of PL/I and I think it's very well-suited to the work it's put to there
(reading fixed-length record-oriented files, mucking with the contents and
writing back to fixed-length record-oriented files).  I'm not looking
forward to telling them that the clear, simple file mappings and
read/writes they're used to can't be done as abstractly in C.  But
that's _very_ different from saying that they can't be done.  And my
executables are a lot smaller and a lot faster then theirs are. :)

/**James Robinson***********************            
  "An important goal of almost every graphics program is to draw pictures on
 the screen."    -- Neider, Davis & Woo, _OpenGL_Programming_Guide_, Chapter 10



Fri, 14 Aug 1998 03:00:00 GMT  
 PL/I and C

Quote:
>MAINFRAME C/370 Unions CAN NOT have Arrays as members,

Which version of C/370?


Fri, 14 Aug 1998 03:00:00 GMT  
 
 [ 37 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. to CS: or not to CS: in F-PC assembler

2. Logo Komeniusz PL (Logo Comenius PL)

3. Derivation of PL/I (was Usenet group for PL/M language)

4. Mapping local files to FILE declarations in PL/I with IBM VisualAge PL./I for Windows

5. Difference PL/1 PL/I

6. What is the difference between DEC PL/1 and OS/390 PL/1

7. Initialization Expressions in PL/I (was ANSI PL/I)

8. Migrating from OS/VS PL/I to VA PL/I

9. PL/I FAQ -- Frequently asked questions about PL/I (minor update)

10. The PL/I Connection (PL/I Newsletter No. 6)

11. How VOS PL/I tames PL/I

12. PL1 JOBS PL/I Jobs PL/1 JOBS

 

 
Powered by phpBB® Forum Software