> Paul wrote: did C have dynamic allocation in FOPEN before MVS UNIX.
Thanks John for pointing out that LE supports dynalloc. It's been many years
since I've looked at application programming in MVS.
> Paul wrote: Please explain dynalloc security exposure in programming
> languages.
In the past is used to be a problem but apparently has become acceptable. The
security exposure back then was that production analysts reviewed production
JCL to verify datasets used. Having delivered SAS/C with our products,
customers would call after an audit about dynalloc. I would tell them that as
long as they restricted access to our products, then there is not an exposure.
The idea was that programmers could copy restricted data (e.g. payroll, SS
numbers, credit cards and ???) to a dataset they owned. In C, it may have been
a simple mistake. In other languages, it was considered willful and intentional
because the programmer must do something unusual. Back then, some companies did
not want programmers to use dynalloc.
> Paul wrote:Consider portability as justification for using C
This is motivated reasoning. Does this make you 5 to 10 times more productive?
How often do you think our programs are relevant to Unix? Very few programs we
write in HLASM are relevant to Unix (even to VM and VSE). MVS is a feature rich
operating system when compared to Unix. Case in point is Charle's product
(SMF). Look at the CBT and you will see the majority do not have any relevance
to any other environment. Also remember that HLASM programmers are much more
willing to use other languages than C programmers.
> Paul wrote: Consider ease of programming as justification for using C
This is motivated reasoning. Specifically mentioned was C printf function. I
believe C functions are part of LE. As such, this should be an easy to call the
LE function from HLASM. It's maybe a 15 line macro to init LE, build parm list,
call function, destroy environment and return result. The programmer would use
a macro call something like #LE_CALL PRINTF,('X %s %i %f',var1,var2,var3).
What is it that makes a C programmer say they are more productive (especially
when they believe they are effective HLASM programmers)?
Thanks, Jon.
On Tuesday, December 19, 2017 8:20 PM, Paul Gilmartin
<[email protected]> wrote:
On 2017-12-19, at 20:51:23, Jon Perryman wrote:
>> I wrote: TSO has the alloc command which can easily be > used in clists. It
>> exists because of MVS UNIX.
> MVS UNIX has nothing to do with TSO ALLOC. When I moved the C FOPEN text, I
> forgot to delete the MVS UNIX senstence. It's FOPEN dynamic alloc only exists
> because of MVS Unix
>
Wasn't C available on MVS before MVS UNIX, and didn't its fopen()
then support dynamic allocation?
> ... and is considered a production MVS security exposure.
>
Please explain that security exposure.
> Most production languages do not support dynalloc for this reason.
>
Which "production languages do not support dynalloc"? HLASM, certainly
a production language in the z world, has SVC 99. Can't both COBOL and
PL/I call BPXWDYN?
> Can anyone give me any example that would justify C programmers belief that C
> is significantly better than HLASM?
>
Consider portability. On how many different hardware architectures
and operating systems can a given HLASM program run? How many for C?
Consider ease of coding. What's the HLASM equivalent of:
#include <stdio.h>
int main( void ) {
printf( "Hello world!\n" );
return( 0 ); }
(You might shortcut this with WTO. If you do, let's change both
our examples to write to a file.)
-- gil
