anyone migrated successfully to Enterprise PL/I? 
Author Message
 anyone migrated successfully to Enterprise PL/I?


Date: Mon, 17 Mar 2003 11:20:47 +0100

| > >>>PL/I has been able to do that (viz., report invalid decimal data)
| > >>>since it was first introduced in 1966.
| > >
| > > A present-day ON unit for printing decimal variables (e.g. D) could consist of:
| > > ON ERROR SNAP BEGIN;
| > >    IF VALID (D)
| > >       THEN PUT SKIP DATA (D);
| > >    ELSE
| > >       PUT SKIP LIST ('D=' || HEX (D) || ' (INVALID DECIMAL DATA)');
| > > END;
|
| > In other words, if you already know what the bug is, you can alter the
| > program to explain what the bug is.  Some people might find that less
| > than useful.
| It looks to me like you need to code an ON block for every decimal variable
| in the program.

Good heavens no!  Only one ON-unit is needed.

| A bit long-winded.

Can be considerably simplified by the pre-processor.

| Can you use ONSOURCE instead of D in the above example?

No.

| Tim.



Wed, 07 Sep 2005 20:19:48 GMT  
 anyone migrated successfully to Enterprise PL/I?

Date: 18 Mar 2003 08:26:19 GMT

|
| > When a subscript error or substring reference occurs,
| > the SUBSCRIPTANGE or STRINGRANGE/STRINGSIZE conditions is
| > raised. (assuming that the respective condition prefixes have
| > enabled the conditions)
|
| >    When the condition is raised, memory has NOT been corrupted.
| > It is perfectly safe to print out values etc and
| > to proceed from some safe point.
| Do you really run production programs with SUBSCRIPTRANGE and STRINGRANGE
| enabled?

Production is the last place where you can afford to
have the code fall over for something trivial.  (Classic case: The Ariane 5
space rocket blew up when an integer overflow occurred.)

The cost is trivial for most applications, with considerable
confidence in being able to recover from trivial errors.

In the case of STRINGSIZE, is is essential to have this enabled in
VisualAge PL/I, otherwise a simple string assignment can corrupt storage.

In the case of STRINGRANGE, the code performs an automatic fixup
so that a safe substring is taken.

SUBCRIPTRANGE, STRINGRANGE, STRINGSIZE, SIZE, FIXEDOVERFLOW
should always be enabled in production programs, IMHO.

I guess the real answer to your query "Do you really run production
programs with ... enabled" is: Can you afford not to?

| Have you done some benchmarks of the overhead this adds in terms
| of CPU and virtual storage use?

CPU speed have increased and storage costs have decreased phenomenally
over the years.

| Enabling these is advice I give periodically to batch programmers who have
| encountered a particular condition for which the most likely cause is
| having used a bad subscript for an array or string. It is always
| interesting to compare their bold assurance that they can't possibly
| have such a problem with the more subdued manner in which they come
| back later and confirm that they did in fact have a bad subscript.

The above-mentioned conditions should always be enabled for program
testing.



Wed, 07 Sep 2005 20:22:49 GMT  
 anyone migrated successfully to Enterprise PL/I?

Quote:

> Production is the last place where you can afford to
> have the code fall over for something trivial.  (Classic case: The Ariane 5
> space rocket blew up when an integer overflow occurred.)

Actually, it is the last place that you can afford to find out that
someone's error handling exit doesn't doesn't restore the DBs to a
point of consistency.

The IMS-L discussion list recently had a posting by someone running
with the default value for ABTERMENC whose DBs were left partially
updated after a COBOL SB37 abend terminated quietly without even a
non-zero return/completion code.

Quote:

> The cost is trivial for most applications, with considerable

Too trivial for you to put a % figure on, it seems.

Quote:
> confidence in being able to recover from trivial errors.

Are you familiar with the Classical Greek concept of Hubris?

Quote:

> I guess the real answer to your query "Do you really run production
> programs with ... enabled" is: Can you afford not to?

I certain can't afford to pay for another CPU in any of the
9672s in the Sysplex. My managers say that it's not in their
budgets either.

Quote:

> | Have you done some benchmarks of the overhead this adds in terms
> | of CPU and virtual storage use?

> CPU speed have increased and storage costs have decreased phenomenally
> over the years.

I'll take that as a NO.

While CPU and DASD costs have dropped the amount of work being done
on mainframe computers seems to at least keep pace. As processing
becomes cheaper automation and IT gets applied to more and more tasks.

Getting a figure for the marginal cost of DASD seems to be a futile
quest around here. The most recent figure I was quoted was CDN$4K
per Gbyte per year. That seems a bit steep in view of the fact that
if I spend $4000 for a desktop machine I'd expect to it have at least
that much RAM, let alone at least 10 times that on a hard drive
and a few Gbytes of writeable DVD diskspace.

The storage types didn't really challenge that number when I ran it by
them recently, but they did try to tell me that I'm also paying for
"backup". I explained to them that as a DB Admin I run my own backups,
thank you very much, but they didn't offer to cut the rate.

Quote:

> The above-mentioned conditions should always be enabled for program
> testing.

"Migrate what you test, test what you are going to migrate.", which brings
it back to exactly what the overhead is.


Thu, 08 Sep 2005 03:38:03 GMT  
 anyone migrated successfully to Enterprise PL/I?

Quote:
> | > >>>PL/I has been able to do that (viz., report invalid decimal data)
> | > >>>since it was first introduced in 1966.
> | > >
> | > > A present-day ON unit for printing decimal variables (e.g. D) could
consist of:
> | > > ON ERROR SNAP BEGIN;
> | > >    IF VALID (D)
> | > >       THEN PUT SKIP DATA (D);
> | > >    ELSE
> | > >       PUT SKIP LIST ('D=' || HEX (D) || ' (INVALID DECIMAL DATA)');
> | > > END;
> |
> | > In other words, if you already know what the bug is, you can alter the
> | > program to explain what the bug is.  Some people might find that less
> | > than useful.
> | It looks to me like you need to code an ON block for every decimal
variable
> | in the program.

> Good heavens no!  Only one ON-unit is needed.

Well alright, one ON unit, and x-hundred IFs.

Quote:
> | A bit long-winded.

> Can be considerably simplified by the pre-processor.

With all the pros and cons of usign the preprocessor thrown in, which has
been discussed here quite often.
Still, if it's the only practical way to do it.....

Quote:
> | Can you use ONSOURCE instead of D in the above example?

> No.

Just a thought.


Fri, 09 Sep 2005 16:51:09 GMT  
 anyone migrated successfully to Enterprise PL/I?

Quote:

> > | > >>>since it was first introduced in 1966.
> > | > >
> > | > > A present-day ON unit for printing decimal variables (e.g. D) could
> consist of:
> > | > > ON ERROR SNAP BEGIN;
> > | > >    IF VALID (D)
> > | > >       THEN PUT SKIP DATA (D);
> > | > >    ELSE
> > | > >       PUT SKIP LIST ('D=' || HEX (D) || ' (INVALID DECIMAL DATA)');
> > | > > END;
> > |
> > | > In other words, if you already know what the bug is, you can alter the
> > | > program to explain what the bug is.  Some people might find that less
> > | > than useful.
> > | It looks to me like you need to code an ON block for every decimal
> variable
> > | in the program.

> > Good heavens no!  Only one ON-unit is needed.

> Well alright, one ON unit, and x-hundred IFs.

No, a short pre-processor procedure.


Mon, 12 Sep 2005 08:18:27 GMT  
 anyone migrated successfully to Enterprise PL/I?

Quote:


>>Well alright, one ON unit, and x-hundred IFs.

> No, a short pre-processor procedure.

Would you be good enough to exhibit this short preprocessor procedure?


Mon, 12 Sep 2005 14:04:26 GMT  
 anyone migrated successfully to Enterprise PL/I?

Date: 22 Mar 2003 19:38:03 GMT

|
| > Production is the last place where you can afford to
| > have the code fall over for something trivial.  (Classic case: The Ariane 5
| > space rocket blew up when an integer overflow occurred.)
|
| Actually, it is the last place that you can afford to find out that
| someone's error handling exit doesn't doesn't restore the DBs to a
| point of consistency.

Sounds like some quality control is needed.

| The IMS-L discussion list recently had a posting by someone running
| with the default value for ABTERMENC whose DBs were left partially
| updated after a COBOL SB37 abend terminated quietly without even a
| non-zero return/completion code.
|
| > The cost is trivial for most applications, with considerable
!
| Too trivial for you to put a % figure on, it seems.
|
| > confidence in being able to recover from trivial errors.
|
| Are you familiar with the Classical Greek concept of Hubris?
|
| > I guess the real answer to your query "Do you really run production
| > programs with ... enabled" is: Can you afford not to?
|
| I certain can't afford to pay for another CPU in any of the
| 9672s in the Sysplex. My managers say that it's not in their
| budgets either.
|
| > | Have you done some benchmarks of the overhead this adds in terms
| > | of CPU and virtual storage use?
|
| > CPU speed have increased and storage costs have decreased phenomenally
| > over the years.
|
| I'll take that as a NO.
.
Don't make wild (and wrong) assumptions.
Back in the days of mainframes with 32K, 64K, and 128K etc main memories,
when every little byte counted, and when instructions such as
multiply took eons, the cost of subscript checks was relatively
high in both memory use and in execution time.
.
Since then, memory became ultra cheap and instruction execution times
came down considerably.  So much so that the execution time costs
have become negligible, as have problems about fitting in the
code needed for subscript checks.
.
So, in answer to your question about benchmarks, yes, of course I have
done benchmarks, and it is clear that you need to do some
for your own applications.
.
With subscript checking etc enabled, a program can be made virtually
failsafe.  Better than having the program crash on a busy day or
at 2 o'clock in the morning!



Tue, 13 Sep 2005 05:16:23 GMT  
 anyone migrated successfully to Enterprise PL/I?


Quote:
>Back in the days of mainframes with 32K, 64K, and 128K etc main
>memories, when every little byte counted, and when instructions such
>as multiply took eons, the cost of subscript checks was relatively
>high in both memory use and in execution time.

I agree with your position that (NOSUBSCRIPTRANGE) and (NOSTRINGRANGE)
are usually wrong today; I disagree as to whether they were justified
in the past, for several reasons.

 1. The 16K and 32K, etc., machines didn't run much PL/I.

 2. You don't need multiply to check range

 3. Few of the old machines were piplined, so there was no
    performance issue with I-buffer flushes

 4. Compiles were slow. Saving the cost of one compile could
    pay for the overhead of quite a bit of error checking.

 5. Just as today, having a production job corrupt the data
    is expensive in manpower, recovery and rerun time.

So *I'd* be interested in benchmarks showing that suppressing those
checks was cost effective on a 360/50 or 360/65. I suspect that it
usually wasn't.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not



Wed, 14 Sep 2005 01:27:24 GMT  
 anyone migrated successfully to Enterprise PL/I?

Quote:

> >Back in the days of mainframes with 32K, 64K, and 128K etc main
> >memories, when every little byte counted, and when instructions such
> >as multiply took eons, the cost of subscript checks was relatively
> >high in both memory use and in execution time.

> I agree with your position that (NOSUBSCRIPTRANGE) and (NOSTRINGRANGE)
> are usually wrong today; I disagree as to whether they were justified
> in the past, for several reasons.

>  1. The 16K and 32K, etc., machines didn't run much PL/I.

DOS PL/I ran in a 32K machine.

Quote:
>  2. You don't need multiply to check range

You do for 2-dimensional arrays and higher.
The time penalty was fairly steep for multiplication,
where the effects of SUBRG were quite noticeable.
Quote:
>  4. Compiles were slow. Saving the cost of one compile could
>     pay for the overhead of quite a bit of error checking.

>  5. Just as today, having a production job corrupt the data
>     is expensive in manpower, recovery and rerun time.

> So *I'd* be interested in benchmarks showing that suppressing those
> checks was cost effective on a 360/50 or 360/65. I suspect that it
> usually wasn't.

> --
>      Shmuel (Seymour J.) Metz, SysProg and JOAT



Wed, 14 Sep 2005 17:04:16 GMT  
 anyone migrated successfully to Enterprise PL/I?

Quote:


>> 1. The 16K and 32K, etc., machines didn't run much PL/I.
> DOS PL/I ran in a 32K machine.

PL/I (D) ran in a 16KiB machine, in fact, but it didn't have
SUBSCRIPTRANGE anyway.

Quote:
>> 2. You don't need multiply to check range
> You do for 2-dimensional arrays and higher.

No you don't.  Multiplication is not only not needed for the purpose, it
has no valid use at all.

--
John W. Kennedy
"Only an idiot fights a war on two fronts.  Only
the heir to the throne of the kingdom of idiots
would fight a war on twelve fronts."
   -- "Babylon 5"



Thu, 15 Sep 2005 07:35:25 GMT  
 anyone migrated successfully to Enterprise PL/I?

Quote:

> > | > >>>PL/I has been able to do that (viz., report invalid decimal data)
> >>Well alright, one ON unit, and x-hundred IFs.

> > No, a short pre-processor procedure.

> Would you be good enough to exhibit this short preprocessor procedure?

%DUMP:
   PROCEDURE  (L1, L2, L3, L4, L5, L6);
      DECLARE (L1, L2, L3, L4, L5, L6) CHARACTER;
      DECLARE ARGS CHARACTER;
      DECLARE J FIXED;
      ARGS = MACARGS();
      DO J = 1 TO ITEMCOUNT(ARGS);
         ANSWER ('IF VALID (' || ITEM(ARGS, J) || ') THEN' ) SKIP COLUMN (6);
         ANSWER ('PUT SKIP DATA (' || ITEM(ARGS, J) || ');' ) SKIP COLUMN (9);
         ANSWER ('ELSE PUT SKIP LIST ( ''' || ITEM(ARGS,J) || '='' || HEX(' ||
            ITEM(ARGS,J) || ')' || ' , '' (INVALID DECIMAL);'');' ) SKIP COLUMN (6);
      END;
   %END DUMP;
   %ACTIVATE DUMP;


Thu, 15 Sep 2005 08:32:38 GMT  
 anyone migrated successfully to Enterprise PL/I?

Quote:

> >> 1. The 16K and 32K, etc., machines didn't run much PL/I.

> > DOS PL/I ran in a 32K machine.

> PL/I (D) ran in a 16KiB machine, in fact, but it didn't have
> SUBSCRIPTRANGE anyway.

> >> 2. You don't need multiply to check range

> > You do for 2-dimensional arrays and higher.

> No you don't.  Multiplication is not only not needed for the purpose, it
> has no valid use at all.

I have to disagree.

   To transform 2-D addressing to 1-D addressing requires the
computation n*(i-1)+j for A(i,j).
   Note that, in general, n is determined at run time; that
is, it is not constant.

   Transformation of 3-D to 1-D requires two multiplications, etc.

Quote:
> --
> John W. Kennedy
> "Only an idiot fights a war on two fronts.  Only
> the heir to the throne of the kingdom of idiots
> would fight a war on twelve fronts."
>    -- "Babylon 5"



Thu, 15 Sep 2005 08:38:47 GMT  
 anyone migrated successfully to Enterprise PL/I?

Quote:



>>>>1. The 16K and 32K, etc., machines didn't run much PL/I.

>>>DOS PL/I ran in a 32K machine.

>>PL/I (D) ran in a 16KiB machine, in fact, but it didn't have
>>SUBSCRIPTRANGE anyway.

>>>>2. You don't need multiply to check range

>>>You do for 2-dimensional arrays and higher.

>>No you don't.  Multiplication is not only not needed for the purpose, it
>>has no valid use at all.

> I have to disagree.

>    To transform 2-D addressing to 1-D addressing requires the
> computation n*(i-1)+j for A(i,j).
>    Note that, in general, n is determined at run time; that
> is, it is not constant.

>    Transformation of 3-D to 1-D requires two multiplications, etc.

That is not correct checking.

--
John W. Kennedy
"Only an idiot fights a war on two fronts.  Only
the heir to the throne of the kingdom of idiots
would fight a war on twelve fronts."
   -- "Babylon 5"



Thu, 15 Sep 2005 11:17:52 GMT  
 anyone migrated successfully to Enterprise PL/I?


Quote:
>DOS PL/I ran in a 32K machine.

PL/I (D) was such a restricted subset that I can't believe it saw much
use.

Quote:
>You do for 2-dimensional arrays and higher.

No you don't. You need multiplication to calculate offsets, not to
check subscripts for range. If the compiler used multiplication as
part of its subscript checking, then it was not just inefficient, but
wrong; such code would allow some invalid combinations of subscripts
to be treated as in range.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not



Thu, 15 Sep 2005 11:16:15 GMT  
 anyone migrated successfully to Enterprise PL/I?


Quote:
>   To transform 2-D addressing to 1-D addressing requires the
>computation n*(i-1)+j for A(i,j).

That is, of course, the right answer to the wrong question. The
question is *not* whether you need multiplication to access an element
of a multidimensional array. The question is whether the additional
code for (SUBSCRIPTRANGE) requires a multiplication, and the answer is
an unequivocal NO.

--
     Shmuel (Seymour J.) Metz, SysProg and JOAT

Any unsolicited commercial junk E-mail will be subject to legal
action.  I reserve the right to publicly post or ridicule any
abusive E-mail.

I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me.  Do not



Thu, 15 Sep 2005 11:19:27 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. anyone migrated successfully to Enterprise PL/I?

2. anyone migrated successfully to Enterprise PL/I?

3. anyone running IMS ADF II exits under Enterprise PL/I

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

5. Anyone successfully using VW2.0 with Sybase/Oracle?

6. Anyone successfully using VW2.0 with Sybase/Oracle

7. Anyone successfully using MSSQL 7 with C5EE driver?

8. Has ANYONE Successfully Mixed Clarion w/ ABC?

9. Socket Toosl FTP OLE: Anyone using it successfully?

10. Has anyone successfully compiled Perl5 w/ dynamic loading

11. Anyone successfully used RXSOCK?

12. Anyone running Oberon2 successfully?

 

 
Powered by phpBB® Forum Software