OPTABLE error

[Mark Boonie]

I spent an hour or so fighting with my build environment because I thought it was ignoring my options, but now I think I have an HLASM bug. I'm specifying OPTABLE(ZS6,LIST) as a *PROCESS option. The "Options for this Assembly" page shows that the option has been processed correctly ("3 Invocation Parms OPTABLE(ZS6,LIST)"), so the option should be in effect, but in the opcode-table section of the listing, the mnemonic RISBG doesn't appear, and it's getting flagged in the assembly with message ASMA057E, undefined operation code. (RISBG is a ZS4-level mnemonic.)

I also specified PCONTROL(ON) to try to find any macros that modify the OPTABLE setting, but I didn't find anything.

I seem to recall that OPTABLE processing broke somehow with the APAR that introduced z14 mnemonics -- could this be the problem? And if so, is there a fix? The PTF level I'm using is UI51638.

- mb

[Jonathan Scott]

Ref: Your note of 19 January 2018, 17:50:02 EST

Mark Boonie wrote:
> I spent an hour or so fighting with my build environment because
> I thought it was ignoring my options, but now I think I have an
> HLASM bug. I'm specifying OPTABLE(ZS6,LIST) as a *PROCESS
> option. The "Options for this Assembly" page shows that the
> option has been processed correctly ("3 Invocation Parms
> OPTABLE(ZS6,LIST)"), so the option should be in effect, but in
> the opcode-table section of the listing, the mnemonic RISBG
> doesn't appear, and it's getting flagged in the assembly with
> message ASMA057E, undefined operation code. (RISBG is a
> ZS4-level mnemonic.)

Strangely enough, I already spotted last week that *PROCESS OPTABLE does
not work as it should, while checking an odd result encountered while
setting up tests for the recent APAR PI87412 (where an unknown ACONTROL
OPTABLE value was quietly being ignored, because it was trying to issue
a *PROCESS error message instead of an ACONTROL one).

In particular, if *PROCESS OPTABLE issues a warning that something is
being overriden, it can issue the wrong warning and can end up changing
the OPTABLE name (which it shouldn't) without actually changing the
internal OPTABLE selection mask.

Also, *PROCESS OVERRIDE OPTABLE does not work, apparently because the
code was cloned from code for a *PROCESS option (MACHINE) which does not
support OVERRIDE, even though OPTABLE does support OVERRIDE.

While debugging these problems, we also found other related problems,
so we are doing a thorough review of this area to try to ensure that
all option processing conforms to the documented rules.

We also noted that there are inconsistencies in whether or not a message
is issued when a specified option overrides a previous specified option,
in that although the message is set up internally, some of the keyword
routines fail to use it.

We are attempting to find a reliable solution which will fix these
inconsistencies. We are also considering updating the documentation
to make it extra clear that *PROCESS OVERRIDE effectively serves two
purposes:

1. For an option which can be changed by *PROCESS, the OVERRIDE
option quietly ensures that the specified value is used.

2. For an option which cannot be changed by *PROCESS, the OVERRIDE
option can be used to verify that the intended valid being used,
as it will issue a warning if the value does not match, even
though it cannot change it.

I'd expect to see an internal APAR for this within a few days and a fix
for it within two or three weeks. No guarantees, of course, but if you
don't see anything happening soon enough for your requirements, you're
welcome to raise a PMR yourself.

Jonathan Scott
HLASM, IBM Hursley, UK

[Jon Perryman]

I find it amazing how C programmers believe in the superiority despite overwhelming evidence to the contrary. Surprisingly, the psychological term for this is "motivated reasoning" and I never believed it until now. Below actually transpired yet they still believe that C is superior (even with an examples).
In another newsgroup, someone mentioned that C is THE GOTO system language (specifically mentioning Windows) and that there is very little need for assembler. C is the goto language for Unix. Windows has a lot of assembler which requires their code be written in C#. 
I also commented that C is a weak language compared to HLASM and gave some examples that force bad coding techniques (e.g. XML parser). A C programmer took offence because he had written an efficient XML parser in C. Below is psuedo C logic and the assembler to do the same functionality. Realize the C programmer felt C XML parsing needed less than 10 lines but those 10 lines ended up being the first line in the pseudo code. He did not believe me until I gave him the examples.
Another unhappy C programmer decided to give me an impossible challenge by asking for a program where he could not replace a single line with efficient C code. To be cheeky but technically correct, I responded IEFBR14.
More unhappy, he decided it must be a system program. I required that a C programmer must be able to modify and maintain it once written in C. My choice was IDCCDAL which contains the parser statements for TSO ALTER.
That wouldn't make him happy, so lets make it at least a little fair where at least 10% must be in C and the assembler code must use the techniques we now use. My choice would be all the TSO IDCAM commands.
I've always thought HLASM was good. I now realize It's extremely impressive despite all it's warts. Without HLASM, we would not have z/OS, VSE and VM. Imagine writing MVS in C (no SYS1.MACLIB capabilities or the other features). C programmers are hampered by their choice of programming language. MVS would be another flavor of Unix. Imagine the C version of TSO ALLOC DDN(mydd) DSN(my.dataset) NEW CATLG CYL SPACE(5,5,10) (tso alloc -dmydd -fmy.dataset -n -c -C -p5 -s5 -D10). 
Unix programmers keep mentioning our programs aren't portable. That's true but we could make them portable by implementing their machine architecture and creating macro's to generate code supporting our machine instructions. How arrogant when they think we can't possibly do this but they can write Hercules and z390 that do exactly that? Truthfully it's a question of money and desire. When would any of our programs be useful in their environment. We could leave out all the environment specific code but then it wouldn't be near as useful to us.

HLASM is dismissed as a proper language because it includes machine op codes. Ignore the op codes and evaluate it on it's merits as a language (ease of use and maintainability). I believe that Peter Relson said that HLASM macro's make it impressive. While that is true, it has other important unnoticed (and often unused) features that combine to make it truly impressive. 
E.g. someone mentioned that most programmer code is NORENT assembler because RENT requires initializing and addressing the work area. Coding the init area in the CSECT causes USING problems. They don't realize another CSECT will avoid the conflict.
        macro ,
&l    cballoc &cb,&reg=       aif ('&l' eq '').nolabel&l    EQU *.nolabel anop ,        getmain r,lv=&cb.l,sp=1        lr    &reg,r1        USING &cb,&reg     !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!        LA   R0,R1      mvcl destination        LA    R1,&cb.l  length to move        L    R14,=A(&cb)    mvcl source        LR   R15,R1         length to move               MVCL  (R0),(R14)      init cb         MEND , 
WRK  CSECT ,   anything thing you want in the CBWRKL EQU *-WRK
MYPGM CSECT ,         CBALLOC WRK,R9 
Assembler allows non-linear programming. LOCTR, CSECT, DSECT and more  When used in a macro, the programmer codes a single statement yet the macro generates code in multiple locations. This feature is too often overlooked when coding macro's.
Now for the code comparison. For those who don't know XML, the basics are very simple. <a>data</a> allows you to associate 'data' as element 'a'. While 'data' can be can be actual data, it can also include additional levels of more XML. Basically it's multi-level data encapsulation. <a><b>bbb<c>ccc</c></b><d>ddd</d><d>ddd</d>aaa</a>
Simplified assembler XML sample that could parse the XML above:
    --- asm code before parsing ---    XMLPARSE BEGIN,XMLDATA=????    XMLPARSE   ELEMENT=a     --- element  a  code ---     XMLPARSE  ELEMENT=b,SUBELEM=a      --- element  b  code ---      XMLPARSE ELEMENT=c,SUBELEM=b       --- element c code ---      XMLPARSE ELEMENT=d,SUBELEM=a       --- element d code ---       XMLPARSE END       --- asm code after parsing ---
Pseudo code that shows C programming logic for the XMLPARSE above.
      --- code before parsing ---      parse XML (element_start, element_data, element_end, XMLDATA=???)       --- code after  parsing ---
function element_start    **** called for each <???>  (start of an element)       put flags onto stack       clear flags       if element = 'a' then           a_flag = true       else if element = 'b' & element[-1] = 'a' then            b_flag = true        else if element = 'c' & element[-1] = 'b' & element[-2] = 'a' then              c_flag = true        else if element = 'd' & element[-1] = 'a' then             d_flag = true         else               error invalid element 
function element_data     **** called for data between (not XML elements inside this element)         if a_flag = true then              --- element a code ---         else if b_flag = true then               --- element b code ---         else if c_flag = true then                --- element c code ---          else if d_flag = true then                --- element d code ---
function element_end       **** called for each </???>  (end of the element)          restore flags from stack
----- end of pseudo code -----
If anyone tells you C is superior to HLASM, don't believe it. Have them translate the DCB macro into acceptable functionality in C. By the way, they will tell you it's unnecessary because you only need their concept of I/O (streams).
Regards, Jon.

[Rob van der Heij]

On 22 January 2018 at 07:47, Jon Perryman <jper...@pacbell.net> wrote:

> I find it amazing how C programmers believe in the superiority despite
> overwhelming evidence to the contrary. Surprisingly, the psychological term
> for this is "motivated reasoning" and I never believed it until now. Below
> actually transpired yet they still believe that C is superior (even with an
> examples).
>

I hope you also have other New Year's Resolutions like to give up smoking;
probably easier than a programming language fight :-)

HLASM (with the macro libraries written over the past 40 years) gets beyond
what many people think of when you mention assembler language. Many with a
strong opinion base that on hearsay or lack of familiarity. A Structured
Programming macro library can help avoid goto-spaghetti. The one I use for
CMS Pipelines also adds a procedure concept to do flexible calling of
subroutines. I would not have benefit of using C except when I can take
code written by someone else. If you want to disagree about "superior" you
might first have to agree on the criteria. The least number of non-blank
lines or characters? Shortest execution time? If C were superior, why have
so many new languages been developed based on it? ;-)

Many say the strong point of C is the availability of libraries to call.
Obviously assembler routines can call subroutines and most of us have
extensive libraries available. You can even write HLASM macros to check
parameter lists similar to function prototypes in C. If you put in some
effort to initialize the runtime environment, you can call those C routines
from assembler code as well. But this is nothing compared to the function
call mechanisms in Python for example.

There's probably a good use case for each of the thousands of programming
languages, but how would you pick the right tool for the job? I would say
that when you are comfortable with half a dozen languages in different
classes, you have a good basis to pick the proper tool for the job. As for
your example, I would not try to parse XML in either C or assembler, unless
it's really a very trivial case. You're probably better off with a generic
XML parser to build an abstract tree in memory, or specify the program for
an XML stream processor. Or have lexx and yacc generate the code to parse
your grammar if you don't expect it to be extended often.

Rob

[Ze'ev Atlas]

In the open source project that I maintain, I use C when I have to interface with the source library (written in C) or with LE languages.  I avoid using complex macros and I keep it simple.  I have mercy on people who may need to read my code.  And that is because I've found that it is difficult to read C code that is peppered with unnecessary macros.OTH, when I need to interface with Rexx, HLASM is the king.My point is that as always, one may and should use the right tool, and avoide abuse of the tool.  The problem is once one is inside the culture, he or she do not necessarily see the abuse as suchZe'ev Atlas

Sent from Yahoo Mail on Android

[Dave Wade]

Folks,

Having lived in the Honeywell world of systems programming, where I "moved" from GMAP to B I would say that for many tasks "C" is superior to both "B" and Assembler.
On the Honeywell we delivered many products and tool sets that we could not have done with the programming resource and machine time available using Assember code,
even though GMAP had similar Macro tool kits to those in HLASM. You may wish to dispute this, but a typical programmer will be more productive in "C" than Assembler.

Dave

[Jon Perryman]

Please ignore this Email. I'm testing the formatting because my messages are so badly reformatted.

Sorry for the inconvienence. Jon.

[Jon Perryman]

Resending my original Email because it was badly mangled. Sorry for the inconvenience.

[Charles Mills]

Um, isn't MVS mostly written in PL/X, which I would argue is closer to C than to assembler?

Charles

[Gord Tomlin]

On 2018-01-22 10:44, Jon Perryman wrote:
> I also commented that C is a weak language compared to HLASM and gave some examples that force bad coding techniques (e.g. XML parser). A C programmer took offence because he had written an efficient XML parser in C.

Most programmers (whether C or Assembler) would not write their own XML
parser. They would call a pre-existing parser. FWIW, in the past, I've
done RYO parsing in both languages, and it was less work for me when I
did it in C.

I'm not here to defend C. It certainly has its warts. But just as it's
not good for C programmers to proclaim C to be better than Assembler in
each and every case, it's not good for Assembler programmers to do the
reverse. Both languages have their places, and there are also many
situations where neither one is the best choice.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

[Tony Thigpen]

> Both languages have their places, and there are also many
> situations where neither one is the best choice.

Long Live RPGII. :-)

Tony Thigpen

[Charles Mills]

I'd like to see an XML parser written in RPG II.

Charles

[Steve Thompson]

You provide the compiler and the specs and I'll give it a whirl.

Mind you, I'm rusty with RPGII, but I sure did enough of it in my
DOS -> DOS/VSE days.

And, come to think of it, a customer had it on MVS in SOCAL
during their migration from DOS to MVS (not OS/MFT, but MVS).

Also, I have used the conditional assembly feature of F and H
level assemblers to do some interesting things, such as
generating other languages, JCL, commands for SORT, etc.

Been a l-l-l-long time since I did things like that.

Regards,
Steve Thompson

[Charles Mills]

I'm still working on the business case.

[Tony Thigpen]

I did not say we should use RPGII for a parser. I just think it's still
a good choice for 'some' situations, like plain report writing. (Read
the statement I quoted.)

FYI, I provide support for a large zOS customer that still runs a lot of
RPGII.

Some interesting facts on RPGII.

1) The product is owned by the same people in Germany that own VSE and
zLinux. It is not owned by the language group in Perth.

2) The latest real APAR was back in the 80's. There was a paper-only
APAR in the 90's for Y2K describing how to call the date window routine
from RPGII, but that is not a 'real' APAR.

Personally, I would consider RPGII to be one of the first real 4GL
languages. It seems to meet the definition of a 4GL better than the
definition of a compiler.

Tony Thigpen

[Steve Thompson]

I find it interesting that different report languages that I've
dealt with have a very interesting operational methodology that
reminds me very much of the fixed logic cycle of RPG/RPGII.

Regards,
Steve Thompson

[Jon Perryman]

Rob, what python call mechanism are you referring to? Are you talking about OOP that was taken from C++?

You missed the point. Superiority is not about number of lines, optimal code, opinions or preferences. As a programmer, it's about what designs are you willing to implement in the programming language of you choice? What problems are you willing to solve before you consider the solution too complex to code, maintain and upgrade?


C is a simple language with many functions. For straight forward programming logic, C is fine. When it's a complex problem, it's not so great. Programmers will not use a complex implementation. Below, I discuss XML to make this clear. Before I do, let me show it's not an isolated issue.


Consider MVS with all it's cool features that are accessible thru SYS1.MACLIB. Don't take SYS1.MACLIB so literally. Think about how easily we access those features in HLASM. Show me any possible C implementation that would make it easy to access these features in C (and most other languages too). With that implementation, would a programmer use that feature in C? Is that feature complex to use?


Case in point would be I/O. In Unix, you get 1 very basic I/O method (file streams) without records because records and advanced MVS I/O techniques were too complex for a C usage implementation (you can use structures but it's not that common). Making the DCB / ACB features available to C programmers would be a usage nightmare. This choice has led Unix to a problem called "BIG DATA". Companies are struggling to solve the big data problem.


It's rare that anyone considers MVS I/O as a brilliant idea nor do they understand why it is so revolutionary. The Unix big data problem is simply where data gets out of hand within the scope of available resources (e.g. an overused small amount of data). In Unix, most often the solution is to analyze and modify all the programs involved to use an SQL database. MVS programmers have several easy solutions before they must resort to an SQL database. If they must resort to an SQL database, they are ready because they designed the data around records.


Think about why MVS I/O is such a brilliant idea. Programmers avoid SQL & databases because they require work and maintenance. On the other hand, MVS can often solve the problem without modifying a single program. E.g. convert the file to VSAM and turn on RLS. Define shared resources. Change I/O prioritization. Convert the file to a VSAM KSDS and modify the programs that would benefit from keyed access. We can use record locks instead of data enqueues. I'm sure there are more but you get the idea.


C and Unix are about me (the programmer). I have complete flexibility and can do anything I want. The problem is that everything is the programmers responsibility and they must think about how they need to access data and how to secure it.


MVS is about what's best for the company. Programmers are given wise choices. HLASM makes it easy to provide what programmers need to get the job done efficiently and easily.


At the beginning, I mentioned using XML to demonstrate one of the basic problems with C. There must be over a hundred (red flag 1) available and most written in C. Most are variations of the same basic concept (implement new programming language referred to as a schema (red flag 2) and require 3 user functions be written (element start, element data, element end)(red flag 3)).

If you recall my pseudo C logic, it was wrong but no one complained (red flag 4). We only wish it was that easy to code and understand (e.g. you maintain a list of the active lists in proper sequence or add a schema). It only included 5 elements but would certainly be far more complicated with 30, 40 or more elements. Truthfully, it was just easier to code in assembler than integrate an existing XML parser.

If C had macro's and loctr, you could code a single statement to populate all 3 functions (element start, element data, element end) and generate the schema required by the C XML parser. As I said before, HLASM is a non-linear programming language.

Regards, Jon.

On Monday, January 22, 2018 3:05 AM, Rob van der Heij <rvd...@GMAIL.COM> wrote:


On 22 January 2018 at 07:47, Jon Perryman <jper...@pacbell.net> wrote:

> I find it amazing how C programmers believe in the superiority despite

> overwhelming evidence to the contrary. Surprisingly, the psychological term

> for this is "motivated reasoning" and I never believed it until now. Below

> actually transpired yet they still believe that C is superior (even with an

> examples).

>

[Ze'ev Atlas]

Big data is not what you have described.  It is enormous amount of data that you want to access, analyze and get results in reasonable time.  Reading it in VSAM records is obviously better than teading a stream, but reading 1,000,000,000,000 records takes a lot of time in HLASM, COBOL, or C.  Resolving the big data isdues in platforms like Hadoop rely on parallel processing.  That could be done in any of the sformentioned languges providing the right design.Moreover, a lot of big data is unstructured and cannot easily be transformed to unified recordsZe'ev

[Jon Perryman]

I agree that when coding in a language, you should use the coding standards for that language. As you say, limit the use C macro's because they will become unmanageable if overused. But that's not a problem because it's a horrible macro language.

Jon.

[Charles Mills]

Where do you get your "facts"?

> because records and advanced MVS I/O techniques were too complex for a C usage implementation

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbcpx01/cbc1p224.htm

> you can use structures but it's not that common

Structures are an incredibly common usage in C. A Google search for <c struct> yields 39,900,000 hits.

> If C had macro's

C has macros. (No "macro's" but I assume you meant macros.)

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Jon Perryman
Sent: Monday, January 22, 2018 4:09 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM

[Jon Perryman]

There are several situations where C is very programmer friendly but they tend to be straight forward situations with a small number of permutations. I worked on a product in C that had over 40 different callable functions that would have been far more manageable from HLASM macro's. All were variations of each other.

MVS I/O, IPCS, PC routines, VLF, APF and more would be difficult to use from a C program. Certainly it's possible in C but is it worth the effort.

Jon.

[Jon Perryman]

Big data is a marketing term that describes the large volume of data - both structured and unstructured - that inundates a business on a day-to-day basis.

How is my description different?

Your description sounds like it comes from the marketing material for a product. Are you saying it must involve unstructured data to be big data? Are you saying that a small business can't have big data because they don't meet your volume of data? Are you saying that a smart phone can't possibly have big data? Would a vendor ever tell a customer they don't have big data because they don't meet your requirements?

Hadoop is one of many big data products. Every company defines big data that puts their products into the best light possible. The solution to big data problems depends upon the actual bottleneck and Hadoop may not actually solve that customers issues (e.g. not enough hardware or thrashing on a single disk).

You say a lot of big data is unstructured. Very true because many big data products will only solve structured data problems and are not intended to be used with unstructured data.

Because there are many possible bottlenecks and many possible hardware / software solutions, a big data specialist can help determine how to solve your big data problem. This is how people like Cheryl Watson made their living.

Regards, Jon.

On Monday, January 22, 2018 4:25 PM, Ze'ev Atlas <000001774d97d10...@LISTSERV.UGA.EDU> wrote:

Big data is not what you have described. It is enormous amount of data that you want to access, analyze and get results in reasonable time. Reading it in VSAM records is obviously better than teading a stream, but reading 1,000,000,000,000 records takes a lot of time in HLASM, COBOL, or C. Resolving the big data isdues in platforms like Hadoop rely on parallel processing. That could be done in any of the sformentioned languges providing the right design.Moreover, a lot of big data is unstructured and cannot easily be transformed to unified recordsZe'ev

[Jon Perryman]

I can't say for sure how much is written in PL/X but I suspect a good portion. But there is a substantial portion written in HLASM which would not be written in PL/X. Writing those in PL/X would have make MVS unmaintainalble.

You are correct in the comparison with Metal C.
Sorry if I came across abrasive before. C is a good language and I do program in it when working on embedded systems or projects that exist in C.

Jon.

[Bernd Oppolzer]

Am 22.01.2018 um 17:59 schrieb Gord Tomlin:
> On 2018-01-22 10:44, Jon Perryman wrote:
>> I also commented that C is a weak language compared to HLASM and gave
>> some examples that force bad coding techniques (e.g. XML parser). A C
>> programmer took offence because he had written an efficient XML
>> parser in C.
>
> Most programmers (whether C or Assembler) would not write their own
> XML parser. They would call a pre-existing parser. FWIW, in the past,
> I've done RYO parsing in both languages, and it was less work for me
> when I did it in C.
>

I'm the C programmer who was mentioned by Jon Perryman in the original
post.
In fact, I didn't take offence, but simply defended my decision (of
2001) to write
the XML parser in C and argued that C is a good language to write some
system
related stuff in it.

My boss asked me in 2001 to write a batch input facility (some sort of
command
interface) for our home grown software deployment system (on the
mainframe),
and he decided that it be a XML interface. The system was written in C
(and REXX,
based on DB2). So it was natural for me to write the XML parser in C. If
he had told
me to write it in ASSEMBLER, I would have done that, too.

There was no other parser to be used at this time.

As it turned out, the parser was so good that others in the company
wanted to
use it, too. We added a PL/1 interface to it, so that PL/1 callers could
use it
(and COBOL, and ASSEMBLER, ...)
Because it was written in C, it could used on other platforms (Windows,
Unix,
OS/2), too, which was very helpful, because we also have a large
insurance math
package, which is written in C and deployed on all of those platforms.
In the
end, the XML parser was included into this package.

This would not have been possible, if the parser had been written in
Assembler
in the beginning.

Kind regards

Bernd

[Jon Perryman]

Many XML parsers are available for C. Surely C programmers could find one that meet's their needs.

For assembler, it turns out you are far better off writing one. You eliminate the need for implementing SCHEMA and greatly improve maintainability. For product parms, you can easily specify the field where the data should be placed and forget about coding any assembler for those elements. The break even point around 15 elements.

I'm not sure what RYO is. There are many C tools for parsing so it's quite possible that the RYO syntax was well suited to C. That is not the case for XML.

I agree that C has it's place but where we differ is about the significance of the languages. HLASM's ability to easily solve complex situations has encouraged the development of advanced technologies and solutions (Cloud, big data, SQL, databases, security, data handling techniques, high availability and much more). C is responsible Unix and the development of a huge amount of software. C has encouraged every programmer to be responsible for every aspect of their program and be totally independent of all features in Unix.

Regards, Jon.

On Monday, January 22, 2018 9:00 AM, Gord Tomlin <gt.ibm...@ACTIONSOFTWARE.COM> wrote:


On 2018-01-22 10:44, Jon Perryman wrote:

> I also commented that C is a weak language compared to HLASM and gave some examples that force bad coding techniques (e.g. XML parser). A C programmer took offence because he had written an efficient XML parser in C.

Most programmers (whether C or Assembler) would not write their own XML
parser. They would call a pre-existing parser. FWIW, in the past, I've
done RYO parsing in both languages, and it was less work for me when I
did it in C.

[John McKown]

I will put in my U.S. $0.02.

There is one place where doing something in C is definitely easier than
HLASM, IMO. That is in writing UNIX command processors. Why? The parameter
list coming into C is much easier to code and understand. Basically the C
prototype is: int main(int argc, char *argv[], char *env[]); The parameter
list coming into HLASM is a bit more complicated. Upon entry from the UNIX
exec() function (e.g. from the shell), GPR1 points to a list of 6
addresses: address 1 is a pointer to an int (argc); address 2 is a pointer
to an array of ints which are the lengths of the strings pointed to by list
of string addresses pointed by address 3; address 3 is a pointer to a list
of pointers to the UNIX "operands" (the char *argv[]); address; address 4
points to an int which is the number of addresses of environment variables
pointed by addresses 5&6; address 5 is a pointer to a list of ints for the
length of the corresponding environment variable; address 6 is a pointer to
a list of addresses which point to the environment variable strings.

Example code (not guaranteed to be "the best" or even "good") can be seen
at: https://github.com/JohnArchieMckown/utilities-1/blob/master/SKELETON.s

​A pseudo-C struct of the above would look something like:

struct {
*int argc; /* pointer to argc​ - number of arguments */
*int argvl[]; /* pointer to array of lengths of argument strings
*/
*char argv[]; /* pointer to array of argument strings */
*int envl[]; /* pointer to array of lengths of environment
strings */
*char env[]; /* pointer to array of environment strings */
}



--
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

[Gord Tomlin]

On 2018-01-23 10:06, Jon Perryman wrote:
> I'm not sure what RYO is.

RYO is a TLA for "roll your own".

On 2018-01-22 11:59, Gord Tomlin wrote:
>
> Most programmers (whether C or Assembler) would not write their own XML
> parser. They would call a pre-existing parser. FWIW, in the past, I've
> done RYO parsing in both languages, and it was less work for me when I
> did it in C.
>

All I was saying here is that I have in the past rolled my own XML
parsing in both C and Assembler, and doing so was quicker and easier in
C than in Assembler. Having said that, it didn't take long to realize
that it was much easier to use an off-the-shelf parser than to roll my
own in either language.

[Jon Perryman]

Even IBM C is incomplete as far as MVS I/O techniques. There are multiple area's that are not implemented such as CKD.

Yes, I agree that C struct is being used. What I was calling into question was the frequency and consistency of it's use in writing files. I'm not an application programmer, so I don't have a lot of exposure to applications. From the few times I've seen applications, some use them, others are using them inconsistently (big data issue) and others not at all (big data problem). From the number of people asking how to write structs, I have to question whether it's the norm.


Yes, C has what they call macros but it doesn't have much functionality.

Regards, Jon.

[Paul Gilmartin]

Why do you direct replies to yourself rather than to the list?

On 2018-01-22, at 22:22:43, Jon Perryman wrote:

> I can't say for sure how much is written in PL/X but I suspect a good portion. But there is a substantial portion written in HLASM which would not be written in PL/X. Writing those in PL/X would have make MVS unmaintainalble.
>

How? Is it because of macros? But I thought that most assembler macros
contain a PL/X section, and even that the point of maintenance for data
macros was the PL/X and the assembler was mechanically generated.

-- gil

[Seymour J Metz]

"C has macros"

FSVO. Certainly anybody that has used the macro facilities of, e.g., HLASM, PL/I, would find the C preprocessor to be a pitiable excuse for a macro language.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Charles Mills <char...@MCN.ORG>
Sent: Monday, January 22, 2018 7:49 PM
To: ASSEMBL...@listserv.uga.edu

Subject: Re: Fair comparison C vs HLASM

Where do you get your "facts"?

> because records and advanced MVS I/O techniques were too complex for a C usage implementation

https://secure-web.cisco.com/1YnKr5oIcXFcs9VVV17cYuO6lIYfnRYdS-R4x7wMugYHfWlWTegFsP8WFgGW9rT9K8T03R38ABCWcZ2c43cg7lOy9D3FWJr-xHmlHQykB2xX-mdkW35bxfLdpiIkbiEF0NRz6U-29SR3fd6bbn5QQuVrlZd1-3iIWzTi3ed9hlUVAIh0ZyrTzOvXdlzHz6_BCtsXDIQqIIGKXMogUMY7ceTm6zZ2pQyiGF2Uo0YsYibaGIA0t7h5MIu8EkuhgTnJAFb9VO8GgU8sOfNm_EBbztaUZuWplo6qF2bbxxKcqS9wYX_jCGrCVQmxW8dyIwHmYwIepVoSyN_Wr4mg3vRc6_8GPn5_GM_8TdJfMa2vy0ZG9PR-PfZ0tO5KaTTA2yh3tQmCZaLZswjO3XFlgcT2WTTALcyPzGLuNpgAgFfgtHVMoy0a9mYJO_OEMW00aWd4M/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.cbcpx01%2Fcbc1p224.htm

[Seymour J Metz]

PL/X is close to PL/I and not at all close to C. PL/X also includes imbedded HLASM.

I have no idea what the percentages are, but MVS is written in a mixture of C, HLASM, Pascal (probably gone) and PL/X (under various names).

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Charles Mills <char...@MCN.ORG>

Sent: Monday, January 22, 2018 11:26 AM
To: ASSEMBL...@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM

[Ed Jaffe]

On 1/22/2018 7:44 AM, Jon Perryman wrote:
> If anyone tells you C is superior to HLASM, don't believe it.

I agree with a lot of what you've written. We use SPMs for our coding
(with FLOWASM of course) and a LOT of powerful macros for calling
services, building tables, etc.

One thing I do like from C is that the compiler can optimize the object
code for a particular generation of hardware -- automatically taking
advantage of new instructions as they become available. In HLASM the
instructions are hand-coded and therefore cannot be automatically optimized.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Martin Ward]

There is an old saying "C combines the power of assembly language
with the flexibility of assembly language": the point being
that C as a language is very close to assembly language.

C has few of the powerful abstraction features found in modern
programming languages: automated memory allocation and
garbage collection, first class functions, higher order functions,
closures, hash tables, abstract data types and so on.

C and HLASM both have support for basic, low-level programming
features such as prodecure calls, conditional statements
and while/repeat loops. Both require the programmer to express
their code at a very low level: "close to the metal".

The main advantage of C over HLASM is that C has an optimising compiler.
If performance is of ultimate importance (and why would anyone
use such low-level languages otherwise?) then the C compiler
can automatically provide register allocation, loop unrolling
and procedure inlining where heuristics indicate these
transformations will improve performance.

A good assembler programmer might make reasonable choices
for register allocation on first writing the program:
but will they be willing to recalculate a new register
allocation after each addition or modification to the program?
Will they choose to write optimal, but unstructured
and unmaintainable spaghetti code or readable but
less efficient structured code? With a compiler,
the programmer can write structured code and allow
the optimiser to apply common subexpression elimination,
pointer chasing, loop unrolling, procedure inlining,
and so on, creating mode efficient code which would be
unmaintainable if it had been written that way
in the first place.

Finally, modern C compilers, such as gcc, can perform
whole program optimisation, applying interprocedural
optimisation to all functions and variables, including
statically-linked libraries.

--
Martin

Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4

[Charles Mills]

> C has few of the powerful abstraction features found in modern programming languages

Agreed. C++ provides some of those.

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Martin Ward
Sent: Tuesday, January 23, 2018 1:26 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM

[Jon Perryman]

For some reason, the listserver is not changing the reply-to address for my messages. I'm using yahoo mail web interface. Does anyone know if there is a fix for this?

I assume that Assembler source and macros that contain PL/X comments are generated by PL/X. I also assume that source and macros without these comments are maintained by hand.

Regards, Jon.

[Jon Perryman]

Thanks for correcting me on PL/X. I've never coded PL/1 so I was going by the samples. Is there somewhere that compares PL/1 with C so that I can understand the differences. I thought that the difference was mostly look and feel.

I dislike the C asm interface. Too bad we don't have access to PL/X.

Thanks, Jon.

[Jon Perryman]

I love the structured programming macro's (SPM). They make the code so much more readable, logical and maintainable.  My only suggestion would be logical indentation (> and < in place of the label where >>> represents 3 indents).  

As for C optimization, do you think IBM changes it as new instructions are implemented? I would have thought the reducing CPU workload would be a downside for IBM.
There are many things I like about C. It's far more accessible to the average person and is a vast improvement to non-IBM asm.  
Regards, Jon.

[Jon Perryman]

> There is an old saying "C combines the power of assembly language
> with the flexibility of assembly language": the point being
> that C as a language is very close to assembly language.

LOL. We are discussing HLASM. Have you used the assemblers in the comparison.

> Both require the programmer to express
> their code at a very low level: "close to the metal".

LOL. To the contrary, HLASM is often used to abstract the programmer from the hardware. In the past, it was used for IO, CICS and IMS definitions. I believe it was used for the MVS stage 1 build. It's used for TSO parsing. I used it to allow easy form creation. I'm sure there are many more.

The alternative in C would require the creation of new languages because C does not allow for this flexibility. Case in point is XML where the C solution is the new programming language called "schema" (which by the way has many varied flavors). Instead of creating new languages, the developers were able to quickly, easily and consistently create these solutions and concentrate on their product design.

> The main advantage of C over HLASM is that C has an optimizing compiler.

C programmers are given a task and they do it well within the limitations of that tool. It's not their fault but "garbage in, garbage out". You can do all the mechanical optimization possible, but at the end of the day, the language forces certain techniques. Case in point is XML. Over the years with several C implementations, the basic design has not changed. HLASM can on the other hand uses abstraction to allow programmers to easily and optimally generate code. In fact, HLASM is one of the only languages that can significantly alter it's behavior on the fly. For instance, Ed Jaffe specifically mentioned SPM (e.g. IF opcode).

Regards, Jon.

[Dave Wade]

I think that this article :-

https://www.theregister.co.uk/2018/01/23/serverless_exhilarating_terrifying_ridiculous_name/

shows the futility of this discussion. Note that its about software development, not about hardware. It illustrates that in most cases there is more than one way to get from a to b.
.. given a shortage of good system developers lets make the process simpler...
.. no matter that the hardware required to deliver the process...

So in the last week I have sent a few emails, bought a couple of things on Amazon, searched in google, and unusually flown on a plane. Most of the IT things I do do not involve mainframes, or assembler, even at the lowest level.
Yes when I use banking, or if I fly, but note that as far as I know in the UK Air Traffic control no longer uses real IBM mainframes. There is still mainframe code buried in there, but its run under emulation. The last failure was in the mainframe code when a table over flowed..

http://www.computerweekly.com/news/4500246924/Nats-failure-down-to-bug-from-teh-90s-and-redundant-code

So in terms of new systems the world has moved on. The old world still exists, but its ring fenced because its getting too hard to change the core business logic, not because its Assembler, COBOL or Fortran...

Dave

> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> LI...@LISTSERV.UGA.EDU] On Behalf Of Jon Perryman
> Sent: 24 January 2018 06:00
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: Fair comparison C vs HLASM
>

[Peter Relson]

Not that I'm a fan of C but I'm surprised just about none of the comments
have mentioned metal C, especially when there are comments directed
towards using some of the assembler-only interfaces and thus challenging
how to use those in C..

<snip>

But there is a substantial portion written in HLASM which would not be

written in PL/X. Writing those in PL/X would have make MVS unmaintainable.

</snip>

The second sentence is untrue, unless you're thinking of some product like
JES which historically has made its source available for customer
modification.

Peter Relson
z/OS Core Technology Design

[Paul Gilmartin]

On 2018-01-24, at 05:44:24, Peter Relson wrote:
> <snip>
> But there is a substantial portion written in HLASM which would not be
> written in PL/X. Writing those in PL/X would have make MVS unmaintainable.
>
> </snip>
>
> The second sentence is untrue, unless you're thinking of some product like
> JES which historically has made its source available for customer
> modification.
>

Hmmm... Can anyone think of a way to relieve that constraint?

-- gil

[Seymour J Metz]

Like many old sayings, it's worth what you paid for it. The z instruction set includes operations far more powerful than anything in C, and the lack of a Turing complete macro language makes C highly inflexible.

C may be similar to SOAP 2 on the 650; it's certainly not similar to any assembler that I used in the last half century.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Martin Ward <mar...@GKC.ORG.UK>
Sent: Tuesday, January 23, 2018 4:26 PM
To: ASSEMBL...@listserv.uga.edu

Subject: Re: Fair comparison C vs HLASM

[Seymour J Metz]

Yes and no. If complicated operations are coded inside macros, the macro can generate different code for different targets. BTDT,GTTS.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Ed Jaffe <edj...@PHOENIXSOFTWARE.COM>
Sent: Tuesday, January 23, 2018 4:25 PM

To: ASSEMBL...@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM

[Charles Mills]

> I would have thought the reducing CPU workload would be a downside for IBM.

One might think that.

The reality is that cycle times are not getting any faster. A z14 does not execute z10 machine instructions significantly (any?) faster than a z10. One way to get customers to buy a new box -- VERY important to IBM -- is to promise that their programs will run faster. That only happens if the compiler exploits the new instructions. There are "business problems" that a z14 can solve faster than a z10, given compiler support of new instructions.

This has been a HUGE area of emphasis of late for the COBOL compiler team. Less so I think for C/C++, but still an emphasis.

Charles

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Jon Perryman
Sent: Tuesday, January 23, 2018 5:11 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM

[Rob van der Heij]

On 24 January 2018 at 18:33, Charles Mills <char...@mcn.org> wrote:

>
> The reality is that cycle times are not getting any faster. A z14 does not
> execute z10 machine instructions significantly (any?) faster than a z10.
>

The second sentence does not follow from the first one. While a single
instruction may take (in many cases) the same number of clock cycles,
improved pipeline and out-of-order execution with deeper and wider cache
makes that a series of instructions often does run quicker than before.
Workloads that just didn't fit in cache anymore before may well fit now.
I'm frequently surprised by the number of extra instructions that you can
sneak into the code without slowing it down. Add to that the SMT support
for specialty engines.

One of the reasons for investing in those aspects of a CPU is that a fair
amount of the instructions executedare in programs that may never get
compiled again. Would be interesting to know which percentage of the
executed instructions are plain old S/370 ones...

Rob

[Tom Marchant]

On Wed, 24 Jan 2018 01:10:33 +0000, Jon Perryman wrote:

>As for C optimization, do you think IBM changes it as new instructions are implemented?

Of course they do. Aren't you familiar with the ARCH parameter on the IBM C compiler? ARCH(12) is for thte z14.

--
Tom Marchant

[Charles Mills]

I know, it was an e-mail, not a white paper.

One type of optimization is simply arranging the instructions better. Along with the ARCH parameter there is a TUNE parameter.

> programs that may never get compiled again

And for those, IBM has the Automatic Binary Optimizer. https://www.ibm.com/us-en/marketplace/improved-cobol-performance

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Rob van der Heij
Sent: Wednesday, January 24, 2018 12:24 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM

[Paul Raulerson]

> On Jan 24, 2018, at 10:14 AM, Seymour J Metz <sme...@GMU.EDU> wrote:
>
> Like many old sayings, it's worth what you paid for it. The z instruction set includes operations far more powerful than anything in C, and the lack of a Turing complete macro language makes C highly inflexible.
>

I am not sure that really makes sense. What exactly do you feel is “more powerful” about the zArch instruction set than “anything” in the C language? Not that they are exactly comparable to be honest, but curiosity gets the better of me here.

The C language was actually modeled on the PDP-11 instruction set, and designed to make writing programs on a very rudimentary UNIX possible. Check out the AT&T Bell Laboratories Technical Journal, October 1984, Vol 63, No 8., Part 2 for just tons and tons of interesting details about that.

But long and short, if you know PDP-11 or VAX assembler, a great deal of the C language is very familiar to you.

That happened in about 1972. In 1973, the entire kernel for the then new Unix operating system was rewritten in C. To this day, the greatest part of any UNIX or UNIX derived kernel is still written in C, and it works just fine as a system programming language.

As for Macros, well, C macros are generally much simpler than HLASM, though with good reason. Most of the functionality embedded in Macros off HLASM is provided by the standard C libraries. Want to open a file? It is the same call on just about any platform. The c libraries are specific to each platform. Want to cross compile for a totally different platform? Easy peasy, just add a flag into the compile indicating the platform. And so on and so on.

I think it can be argued that the c library provides a complete, and easily extended or modified equivalent of HLASM macro processing.

Now, when you get into modern C with typing and so many other built in libraries, you can *still* make an argument. :)

But the most probably truth is that C is far more efficient to program in than HLASM.

A few years ago, a friend of mine declared he could write anything faster than the GCC C compiler, and his program would run faster. Oh, I couldn’t resist…

I asked him to write a program to add 1 to a value 100 million times then print out the answer. He dived in and wrote a sweet little assembler program, assembled and linked it (under z/Linux) and it ran like greased lightening.

Of course, the C compiler took this:

#include <stdio.h>

int main(int argc, char *argv[]) {
int c=0;
int x=0;

for (x=0; x< 100000000; x++) { c++; }

printf ("\nThe final value is [%d]\n", c);
}


and optimized it during compile time.

In fact it optimized it so much it simply generated a LHI of a register with 100000000 in it. (grin) Needless to say, it ran somewhat faster than my friend’s program. Even counting the screen print. :)

> C may be similar to SOAP 2 on the 650; it's certainly not similar to any assembler that I used in the last half century.

Must have missed the DEC PDP and VAX line...

[Glen]

(snip on optimizing and compilers)

> On January 24, 2018 at 8:54 PM Paul Raulerson wrote:
>
> Of course, the C compiler took this:
>
> #include
>

> int main(int argc, char *argv[]) {
> int c=0;
> int x=0;
>
> for (x=0; x< 100000000; x++) { c++; }
>
> printf ("\nThe final value is [%d]\n", c);
> }
>
>
> and optimized it during compile time.
>
> In fact it optimized it so much it simply generated a LHI of a
> register with 100000000 in it. (grin) Needless to say, it ran somewhat
> faster than my friend’s program. Even counting the screen print. :)

> ite: http://www.gkc.org.uk/gkc | Erdos number: 4

There is a story from the OS/360 days of a popular Fortran benchmark
that evaluated
complicated math functions and such, all done using statement functions.

It seems that Fortran H expands statement functions inline, and also
does constant evaluation
at  compile time.

As in the above example, the compiler evaluated the whole thing at
compile time
(very slowly) and at run time printed out the precomputed value (fast).

If Fortran H could do it 40 years ago, C compilers should do it today.
(But I don't know that Fortran H did loop evaluation.)

-- glen

[Dave Wade]

> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-

> LI...@LISTSERV.UGA.EDU] On Behalf Of Glen
> Sent: 25 January 2018 08:02
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: Fair comparison C vs HLASM
>

I don't know if Fortran H does loop unrolling, but some compilers that are targeted at Vector Processors do.
FORTRAN can be a pig of a language though, especially with a poor compiler. Even worse, on two dimensional arrays, the data is stored as columns, not rows.
(I think that’s correct. So if you vary the last subscript, you leap all over storage. Typically Fortran users want to write code where the last subscript varies fastest resulting in excessive paging.
Reversing the subscript order in such programs can produce a significant performance improvements.

>
> -- glen

Dave

[Rob van der Heij]

On 25 January 2018 at 10:18, Dave Wade <dave....@gmail.com> wrote:


> I don't know if Fortran H does loop unrolling, but some compilers that are
> targeted at Vector Processors do.
> FORTRAN can be a pig of a language though, especially with a poor
> compiler. Even worse, on two dimensional arrays, the data is stored as
> columns, not rows.
> (I think that’s correct. So if you vary the last subscript, you leap all
> over storage. Typically Fortran users want to write code where the last
> subscript varies fastest resulting in excessive paging.
> Reversing the subscript order in such programs can produce a significant
> performance improvements.
>

Long time ago we evaluated the vector feature and got the relevant FORTRAN
compiler with it. Outcome was that we passed on the vector feature, but
kept the compiler as it got 90% of the improvement also on the non-vector
CPU :-) In those days I could also speed up a PASCAL/VS program by a
factor 5 when I added 6 unused elements to all arrays with 250 elements and
defined the index as integer rather than 1..250.

Rob

[Tom Marchant]

On Wed, 24 Jan 2018 22:54:49 -0600, Paul Raulerson wrote:

>> On Jan 24, 2018, at 10:14 AM, Seymour J Metz wrote:
>>
>> Like many old sayings, it's worth what you paid for it. The z instruction set includes operations far more powerful than anything in C, and the lack of a Turing complete macro language makes C highly inflexible.
>>
>
>I am not sure that really makes sense. What exactly do you feel is “more powerful” about the zArch instruction set than “anything” in the C language?

You can't find any of the more than 1100 instructions in the z/Architecture instruction set that are more powerful than any C language constructs?

>The C language was actually modeled on the PDP-11 instruction set

A very primitive instruction set compared to the current z/Architecture instruction set.

>As for Macros, well, C macros are generally much simpler than HLASM, though with good reason.

Yes, it was easier to code.

>Most of the functionality embedded in Macros off HLASM is provided by the standard C libraries.

Really? I don't think so.

--
Tom Marchant

[Martin Ward]

On 25/01/18 12:53, Tom Marchant wrote:
> You can't find any of the more than 1100 instructions in the
> z/Architecture instruction set that are more powerful than any C
> language constructs?

ISO C includes a construct for inline assembler: so in terms
of individual instructions, C is as powerful as assembler.

On 25/01/18 04:54, Paul Raulerson wrote:
> In fact it optimized it so much it simply generated a LHI of a
> register with 100000000 in it.

This is an extreme example, of course, but consider the more
usual case of a loop or loops which could be optimised
by strength reduction, code motion, fusion, fission, permutation,
unrolling, inversion, splitting, peeling, tiling,
unswitching, etc. etc. As an assembler programmer,
do you write the optimised version of the loop
(which will be hard to understand and maintain)
or the readable version of the loop (which may have
very poor performance)? As a C programmer, there is no problem:
you write the most readable and maintainable version
of the loop and allow the optimiser to generate efficient code.

--
Martin

Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk

G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4

[Tom Marchant]

On Thu, 25 Jan 2018 13:34:59 +0000, Martin Ward wrote:

>ISO C includes a construct for inline assembler: so in terms
>of individual instructions, C is as powerful as assembler.

Are you trying to prove Shmuel's point that "The z instruction set
includes operations far more powerful than anything in C"?

--
Tom Marchant

[Bernd Oppolzer]

Am 25.01.2018 um 14:34 schrieb Martin Ward:
> On 25/01/18 12:53, Tom Marchant wrote:
>> You can't find any of the more than 1100 instructions in the
>> z/Architecture instruction set that are more powerful than any C
>> language constructs?
>
> ISO C includes a construct for inline assembler: so in terms
> of individual instructions, C is as powerful as assembler.
>
> On 25/01/18 04:54, Paul Raulerson wrote:
>> In fact it optimized it so much it simply generated a LHI of a
>> register with 100000000 in it.
>
> This is an extreme example, of course, but consider the more
> usual case of a loop or loops which could be optimised
> by strength reduction, code motion, fusion, fission, permutation,
> unrolling, inversion, splitting, peeling, tiling,
> unswitching, etc. etc. As an assembler programmer,
> do you write the optimised version of the loop
> (which will be hard to understand and maintain)
> or the readable version of the loop (which may have
> very poor performance)? As a C programmer, there is no problem:
> you write the most readable and maintainable version
> of the loop and allow the optimiser to generate efficient code.
>

I would like to add:

Mainframe ASSEMBLER IMHO is the only Assembler language
(or the only instruction set) where humans can write reasonably programs
in.
All other Assemblers or instruction sets lack the same user friendliness
and orthogonality that this platform has from the early days of the 360
system.
If you look around, there aren't much programmers doing Assembler
on other platforms. All the embedded stuff is programmed using C or
C++ or other languages ... because the instruction sets are so weird.
Only on the mainframe Assembler coding is fun.

So: if you want to be really portable, you HAVE NO OTHER CHOICE
but to use C, even if you like ASSEMBLER on the mainframe
(like me, for example). Of course, it would have been a nice
experience, writing my XML parser in Assembler, but I wrote it
in C ... and I could from the beginning support all relevant platforms.
Or my Pascal compiler: it is written in Pascal; only the runtime on
the mainframe is written in ASSEMBLER (to much of it, for my taste;
I will change that, as soon as I have time to do it). On the other
systems, the runtime etc. is written in C.

BTW: I know of an old PL/1 compiler (Multics), which did the same
loop unrolling and outperformed ASSEMBLER programmers this way;
my example goes like this:

SUM = 0;
DO I = 1 to 10000;
   SUM = SUM + I;
END;
PUT SKIP DATA (SUM);

all variables BIN FIXED (31)

the compiler omitted the loop and the computation completely
and simply printed the result.

Sometimes, when I look at the ASSEMBLER or machine code the
compiler generates out of my C coding (especially when the
compiler omits certain C statements completely or moves them
out of the loop), I realize what I should have coded instead
from the beginning :-)

Kind regards

Bernd

[Seymour J Metz]

I'm much more productive in Perl than I ever could be in C, and Perl is far from my favorite language. Further, my Perl code is at least as portable as anything I've ever seen in C.

I would expect those who have programmed in Ada, Python or Ruby to say similar things, although Ruby is certainly not as portable as Perl.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Bernd Oppolzer <bernd.o...@T-ONLINE.DE>
Sent: Thursday, January 25, 2018 1:57 PM
To: ASSEMBL...@listserv.uga.edu

Subject: Re: Fair comparison C vs HLASM

[Seymour J Metz]

CDS is an example of something more sophisticated than C statements, but even on the S/360 there were instructions like TRT.

I'm not sure whether ++ and -- came from the PDP-11 or from the earlier PDP-7/PDP-9. A decent compiler would have optimized x=x+1 and x=x-1 to utilize the increment and decrement features of those machines without having to add them to the language.

If you know VAX assembler, a great deal is missing from C.

The "good reason" is that they were using a machine with a small memory. A large subroutine library is no substitute for a good macro facility.

It can be argued that the 650 was a more powerful machine than the 7030, but will anybody believe the argument?

"Must have missed the DEC PDP and VAX line..."

Close but no cigar. The C preprocessor is also grossly inferior to, e.g., Macro-11. E Unibus plurum.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Paul Raulerson <paul.ra...@ME.COM>
Sent: Wednesday, January 24, 2018 11:54 PM

[Paul Raulerson]

Typos courtesy of my iPhone and my fat fingers!

> On Jan 25, 2018, at 06:53, Tom Marchant <000000a69b48f3b...@LISTSERV.UGA.EDU> wrote:
>
> On Wed, 24 Jan 2018 22:54:49 -0600, Paul Raulerson wrote:
>
>>> On Jan 24, 2018, at 10:14 AM, Seymour J Metz wrote:
>>>
>>> Like many old sayings, it's worth what you paid for it. The z instruction set includes operations far more powerful than anything in C, and the lack of a Turing complete macro language makes C highly inflexible.
>>>
>>
>> I am not sure that really makes sense. What exactly do you feel is “more powerful” about the zArch instruction set than “anything” in the C language?
>
> You can't find any of the more than 1100 instructions in the z/Architecture instruction set that are more powerful than any C language constructs?

Nope. Care to share your opinion with more specifics? I looked at string manipulation and standard math. The 50-60 basic instructions, along with the grande counterparts, all are pretty simple and comparative.

>
>> The C language was actually modeled on the PDP-11 instruction set
>
> A very primitive instruction set compared to the current z/Architecture instruction set.

At the time, both instruction sets were roughly equivalent. Of course, PDP-11 development stopped about 30 years ago, while IBM HLASM has continued to develop, expand, and gain new capabilities.

>
>> As for Macros, well, C macros are generally much simpler than HLASM, though with good reason.
>
> Yes, it was easier to code.

Um, no. I believe HLASM macros were developed more because the mainframe compilers were originally designed as multi pass compilers because of resource limitations. Compile this phase, load a tape. Compile another phase, load another tape. And so on... C did not have those same limitations, probably because C is about 10 years younger than IBM 360 assembler.

Unix at AT&T Bell Labs was originally billed as a text processing system, which it did very well. But that was kind of a smokescreen to justify the development of Unix and C at Bell because Multics was going away.

>
>> Most of the functionality embedded in Macros off HLASM is provided by the standard C libraries.
>
> Really? I don't think so.

Yes really. Might want to rethink that. Or not - you are welcome to think what you like of course.

>
> --
> Tom Marchant

I think it is plain silly to think HLASM is always superior for development purposes to other languages, including C.

In some cases it is superior - such as when bottom up development is called for. It can even fit in well in an Agile/SCRUM environment for goodness sake! And, to top it all off, it is great fun to program in.

But in many cases, other languages are far more efficient to use.It is not a good or bad thing, it just is.

There are ways to increase the usability of HLASM in those sub-optimal use cases, such as usi structured macros. But you often find a lot of resistance to things line that from the HLASM community, and it takes the focus off accomplishing what has to be done and moves it to how to do it. Square Hole, Round Peg type of thing I think. :)

[Glen]

> On January 25, 2018 at 10:57 AM Bernd Oppolzer wrote:
>
(snip)

> I would like to add:
>
> Mainframe ASSEMBLER IMHO is the only Assembler language
> (or the only instruction set) where humans can write reasonably programs
> in.
> All other Assemblers or instruction sets lack the same user friendliness
> and orthogonality that this platform has from the early days of the 360
> system.

VAX is pretty human readable, too.
That was considered important at the time, though just at the
transition away from mostly writing OS in assembler.

But yes, RISC assembler programs are not so readable, and also
x86 (for any value of x) are not so readable.

(snip)

>
> BTW: I know of an old PL/1 compiler (Multics), which did the same
> loop unrolling and outperformed ASSEMBLER programmers this way;
> my example goes like this:
>
> SUM = 0;
> DO I = 1 to 10000;
> SUM = SUM + I;
> END;
> PUT SKIP DATA (SUM);
>

Loop unrolling was a favorite example for the PL/I
preprocessor.  change to %DO and %END and you have an unrolled loop.

[Paul Raulerson]

> On Jan 25, 2018, at 1:43 PM, Seymour J Metz <sme...@GMU.EDU <mailto:sme...@GMU.EDU>> wrote:
>
> CDS is an example of something more sophisticated than C statements, but even on the S/360 there were instructions like TRT.

TRT has to be one of the most elegant instructions anyone ever thought up. I love it, but you still have to build the translation table. You have to build one in C too, so far as I know. The actual code in C is two or three lines, so yes, I would easily concede that TRT is more sophisticated than C code. ;)

> I'm not sure whether ++ and -- came from the PDP-11 or from the earlier PDP-7/PDP-9. A decent compiler would have optimized x=x+1 and x=x-1 to utilize the increment and decrement features of those machines without having to add them to the language.

PDP-7.

>
> If you know VAX assembler, a great deal is missing from C.

(grin)

>
> The "good reason" is that they were using a machine with a small memory. A large subroutine library is no substitute for a good macro facility.
>
> It can be argued that the 650 was a more powerful machine than the 7030, but will anybody believe the argument?
>

I thought it was something like that. Thanks!

> "Must have missed the DEC PDP and VAX line..."
>
> Close but no cigar. The C preprocessor is also grossly inferior to, e.g., Macro-11. E Unibus plurum.

I think every Macro processor - at least until you get to SGML and up - is grossly inferior to Macro-11. To make up for it though, Macro-11 can be pretty impenetrable to figure out if you don’t work with it regularly! :)

-Paul

[Robin Vowels]

From: "Paul Raulerson" <paul.ra...@ME.COM>
Sent: Friday, January 26, 2018 6:48 AM

>> On Jan 25, 2018, at 06:53, Tom Marchant <000000a69b48f3b...@LISTSERV.UGA.EDU> wrote:
>
>> On Wed, 24 Jan 2018 22:54:49 -0600, Paul Raulerson wrote:
>
>>>> On Jan 24, 2018, at 10:14 AM, Seymour J Metz wrote:

>>>> Like many old sayings, it's worth what you paid for it. The z instruction set includes
>>>> operations far more powerful than anything in C, and the lack of a Turing complete macro
>>>> language makes C highly inflexible.

>>> I am not sure that really makes sense. What exactly do you feel is “more powerful” about the
>>> zArch instruction set than “anything” in the C language?

>> You can't find any of the more than 1100 instructions in the z/Architecture instruction set that
>> are more powerful than any C language constructs?

> Nope. Care to share your opinion with more specifics? I looked at string manipulation and standard
> math.

Take a look at TRT, TR, ED, EDMK.
PACK and UNPK can do useful things too.

>> The 50-60 basic instructions, along with the grande counterparts, all are pretty simple and
>> comparative.

>>> The C language was actually modeled on the PDP-11 instruction set
>
>> A very primitive instruction set compared to the current z/Architecture instruction set.

> At the time, both instruction sets were roughly equivalent. Of course, PDP-11 development stopped
> about 30 years ago, while IBM HLASM has continued to develop, expand, and gain new capabilities.

>>> As for Macros, well, C macros are generally much simpler than HLASM, though with good reason.
>
>> Yes, it was easier to code.

> Um, no. I believe HLASM macros were developed more because the mainframe compilers
> were originally designed as multi pass compilers because of resource limitations.
> Compile this phase, load a tape. Compile another phase, load another tape.

Not on our system /360.
Certainly multi-pass compilers were in use.
Magnetic tapes, when used, were for receiving distribition materials,
and for sending similar stuff to other sites.

> And so on... C did not have those same limitations, probably because C is about 10 years younger
> than IBM 360 assembler.

> Unix at AT&T Bell Labs was originally billed as a text processing system, which it did very well.
> But that was kind of a smokescreen to justify the development of Unix and C at Bell because
> Multics was going away.

> I think it is plain silly to think HLASM is always superior for development purposes to other
> languages, including C.

> In some cases it is superior - such as when bottom up development is called for. It can even fit
> in well in an Agile/SCRUM environment for goodness sake! And, to top it all off, it is great fun
> to program in.

> But in many cases, other languages are far more efficient to use.It is not a good or bad thing, it
> just is.

> There are ways to increase the usability of HLASM in those sub-optimal use cases, such as usi
> structured macros. But you often find a lot of resistance to things line that from the HLASM
> community, and it takes the focus off accomplishing what has to be done and moves it to how to do
> it. Square Hole, Round Peg type of thing I think. :)

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Tom Marchant]

On Thu, 25 Jan 2018 13:48:32 -0600, Paul Raulerson wrote:

>> On Jan 25, 2018, at 06:53, Tom Marchant wrote:
>>
>> On Wed, 24 Jan 2018 22:54:49 -0600, Paul Raulerson wrote:
>>
>> You can't find any of the more than 1100 instructions in the z/Architecture instruction set that are more powerful than any C language constructs?
>
>Nope. Care to share your opinion with more specifics?

Shmuel mentioned CDS. Even System/360 had TS.

--
Tom Marchant

[Seymour J Metz]

IMHO IBMAP, Assembler (XF) and Assembler (H) stack up pretty well against Macro-11. I'd rank the S/360 instruction set as better than the PDP-11 but not as good as the VAX-11.

Shirley you mean tools for manipulating SGML, e.g., XSLT, rather than SGML itself.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Paul Raulerson <paul.ra...@ME.COM>

Sent: Thursday, January 25, 2018 3:18 PM

To: ASSEMBL...@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM

> On Jan 25, 2018, at 1:43 PM, Seymour J Metz <sme...@GMU.EDU <mailto:sme...@GMU.EDU>> wrote:
>
> CDS is an example of something more sophisticated than C statements, but even on the S/360 there were instructions like TRT.

TRT has to be one of the most elegant instructions anyone ever thought up. I love it, but you still have to build the translation table. You have to build one in C too, so far as I know. The actual code in C is two or three lines, so yes, I would easily concede that TRT is more sophisticated than C code. ;)


> I'm not sure whether ++ and -- came from the PDP-11 or from the earlier PDP-7/PDP-9. A decent compiler would have optimized x=x+1 and x=x-1 to utilize the increment and decrement features of those machines without having to add them to the language.

PDP-7.

>
> If you know VAX assembler, a great deal is missing from C.

(grin)

>
> The "good reason" is that they were using a machine with a small memory. A large subroutine library is no substitute for a good macro facility.
>
> It can be argued that the 650 was a more powerful machine than the 7030, but will anybody believe the argument?
>

I thought it was something like that. Thanks!

> "Must have missed the DEC PDP and VAX line..."
>
> Close but no cigar. The C preprocessor is also grossly inferior to, e.g., Macro-11. E Unibus plurum.

I think every Macro processor - at least until you get to SGML and up - is grossly inferior to Macro-11. To make up for it though, Macro-11 can be pretty impenetrable to figure out if you don’t work with it regularly! :)

-Paul

>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3

SM











Seymour J Metz














 Reply | 









Today, 1:01 PM

IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu>















Sent Items
































IMHO IBMAP, Assembler (XF) and Assembler (H) stack up pretty well against Macro-11. I'd rank the S/360 instruction set as better than the PDP-11 but not as good as the VAX-11.

Shirley you mean tools for manipulating SGML, e.g., XSLT, rather than SGML itself.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Paul Raulerson <paul.ra...@ME.COM>

Sent: Thursday, January 25, 2018 3:18 PM

To: ASSEMBL...@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM

> On Jan 25, 2018, at 1:43 PM, Seymour J Metz <sme...@GMU.EDU <mailto:sme...@GMU.EDU>> wrote:
>
> CDS is an example of something more sophisticated than C statements, but even on the S/360 there were instructions like TRT.

TRT has to be one of the most elegant instructions anyone ever thought up. I love it, but you still have to build the translation table. You have to build one in C too, so far as I know. The actual code in C is two or three lines, so yes, I would easily concede that TRT is more sophisticated than C code. ;)


> I'm not sure whether ++ and -- came from the PDP-11 or from the earlier PDP-7/PDP-9. A decent compiler would have optimized x=x+1 and x=x-1 to utilize the increment and decrement features of those machines without having to add them to the language.

PDP-7.

>
> If you know VAX assembler, a great deal is missing from C.

(grin)

>
> The "good reason" is that they were using a machine with a small memory. A large subroutine library is no substitute for a good macro facility.
>
> It can be argued that the 650 was a more powerful machine than the 7030, but will anybody believe the argument?
>

I thought it was something like that. Thanks!

> "Must have missed the DEC PDP and VAX line..."
>
> Close but no cigar. The C preprocessor is also grossly inferior to, e.g., Macro-11. E Unibus plurum.

I think every Macro processor - at least until you get to SGML and up - is grossly inferior to Macro-11. To make up for it though, Macro-11 can be pretty impenetrable to figure out if you don’t work with it regularly! :)

-Paul

>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> ________________________________________
> From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Paul Raulerson <paul.ra...@ME.COM>
> Sent: Wednesday, January 24, 2018 11:54 PM
> To: ASSEMBL...@listserv.uga.edu
> Subject: Re: Fair comparison C vs HLASM
>

>> On Jan 24, 2018, at 10:14 AM, Seymour J Metz <sme...@GMU.EDU> wrote:
>>
>> Like many old sayings, it's worth what you paid for it. The z instruction set includes operations far more powerful than anything in C, and the lack of a Turing complete macro language makes C highly inflexible.
>>
>

> I am not sure that really makes sense. What exactly do you feel is “more powerful” about the zArch instruction set than “anything” in the C language? Not that they are exactly comparable to be honest, but curiosity gets the better of me here.
>
> The C language was actually modeled on the PDP-11 instruction set, and designed to make writing programs on a very rudimentary UNIX possible. Check out the AT&T Bell Laboratories Technical Journal, October 1984, Vol 63, No 8., Part 2 for just tons and tons of interesting details about that.
>
> But long and short, if you know PDP-11 or VAX assembler, a great deal of the C language is very familiar to you.
>
> That happened in about 1972. In 1973, the entire kernel for the then new Unix operating system was rewritten in C. To this day, the greatest part of any UNIX or UNIX derived kernel is still written in C, and it works just fine as a system programming language.
>
> As for Macros, well, C macros are generally much simpler than HLASM, though with good reason. Most of the functionality embedded in Macros off HLASM is provided by the standard C libraries. Want to open a file? It is the same call on just about any platform. The c libraries are specific to each platform. Want to cross compile for a totally different platform? Easy peasy, just add a flag into the compile indicating the platform. And so on and so on.
>
> I think it can be argued that the c library provides a complete, and easily extended or modified equivalent of HLASM macro processing.
>
> Now, when you get into modern C with typing and so many other built in libraries, you can *still* make an argument. :)
>
> But the most probably truth is that C is far more efficient to program in than HLASM.
>
> A few years ago, a friend of mine declared he could write anything faster than the GCC C compiler, and his program would run faster. Oh, I couldn’t resist…
>
> I asked him to write a program to add 1 to a value 100 million times then print out the answer. He dived in and wrote a sweet little assembler program, assembled and linked it (under z/Linux) and it ran like greased lightening.
>
> Of course, the C compiler took this:
>
> #include <stdio.h>
>
> int main(int argc, char *argv[]) {
> int c=0;
> int x=0;
>
> for (x=0; x< 100000000; x++) { c++; }
>
> printf ("\nThe final value is [%d]\n", c);
> }
>
>
> and optimized it during compile time.
>
> In fact it optimized it so much it simply generated a LHI of a register with 100000000 in it. (grin) Needless to say, it ran somewhat faster than my friend’s program. Even counting the screen print. :)
>
>
>
>> C may be similar to SOAP 2 on the 650; it's certainly not similar to any assembler that I used in the last half century.
>
>
> Must have missed the DEC PDP and VAX line...
>
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3

[Jon Perryman]

>> I wrote: Writing those in PL/X would have make MVS unmaintainable.
> Peter Relson wrote: The second sentence is untrue,
Peter, it would be interesting to see how PL/X has solved abstract coding techniques. I know DCB is not written in PL/X. Could you show us a short snippet of how you would implement this logic in PL/X? Just enough for us to understand how PL/X solved this would be great. Alternatively, you could show us how TSO commands such as ALTER implemented it's command parsing.

In C, the solutions was a runtime string that was parsed. It does not implement the full functionality of DCB (e.g. 'recfm=fb lrecl=100 blksize=6100').

> Peter Relson wrote: Not that I'm a fan of C but I'm surprised

> just about none of the comments have mentioned metal C

For this topic, it doesn't matter whether it's C or Metal C. They are the same language implementation different standard functions.

I've only taken a quick look at Metal C many years ago. I'm sure it's changed but it was C that eliminated many of the standard library functions without providing robust hardware facility access. Things like PC routines, subpools, switching auth, and more simply were not complete enough to justify it's use. It really seemed to be for basic programming.

Thanks, Jon.

[Paul Gilmartin]

On 2018-01-26, at 18:01:35, Jon Perryman wrote:

>>> I wrote: Writing those in PL/X would have make MVS unmaintainable.
>> Peter Relson wrote: The second sentence is untrue,
> Peter, it would be interesting to see how PL/X has solved abstract coding techniques. I know DCB is not written in PL/X. Could you show us a short snippet of how you would implement this logic in PL/X? Just enough for us to understand how PL/X solved this would be great. Alternatively, you could show us how TSO commands such as ALTER implemented it's command parsing.
>

Isn't a PL/X flavor of DCB provided?

> In C, the solutions was a runtime string that was parsed. It does not implement the full functionality of DCB (e.g. 'recfm=fb lrecl=100 blksize=6100').
>

Is "full functionality of DCB" useful for any OS other than for z/OS? For z/OS,
allocate with BPXWDYN or JCL DD statement and open by fopen("//DDN:..." ).

-- gil

[Robin Vowels]

From: "Tom Marchant" <000000a69b48f3b...@LISTSERV.UGA.EDU>
Sent: Saturday, January 27, 2018 4:51 AM

And MVO and MVN (plus the others that I already mentioned).

[Jon Perryman]

>Paul Gilmartin wrote: Is "full functionality of DCB" useful

> for any OS other than for z/OS? For z/OS,
> allocate with BPXWDYN or JCL DD statement and open by fopen("//DDN:..." ).

BPXWDYN is dynamic allocation and does not provide every feature in DCB. FOPEN allows some DCB parms to be specified as runtime text that is parsed to fill in a DCB. Neither actually provides all functionality provided by DCB.

> Paul Gilmartin Wrote: Isn't a PL/X flavor of DCB provided?
There may be DCB in PL/X. The DCB has many fields to be filled in. Does PL/X require you simply fill in the fields or does it allow abstraction where the programmer specifies a few parameters and the appropriate fields are filled in to fulfill the requirements the programmer specified.

Jon.

[Paul Gilmartin]

On 2018-01-26, at 19:20:02, Jon Perryman wrote:

>> Paul Gilmartin wrote:
>> Is "full functionality of DCB" useful for any OS other than for z/OS? For z/OS,
>> allocate with BPXWDYN or JCL DD statement and open by fopen("//DDN:..." ).
>>
> BPXWDYN is dynamic allocation and does not provide every feature in DCB. FOPEN allows some DCB parms to be specified as runtime text that is parsed to fill in a DCB. Neither actually provides all functionality provided by DCB.
>

Does DCB provide functionality not available via DYNALLOC?

BPXWDYN has a poorly documented side door allowing specification of SVC 99
text units by code.

>> Paul Gilmartin Wrote: Isn't a PL/X flavor of DCB provided?
> There may be DCB in PL/X. The DCB has many fields to be filled in. Does PL/X require you simply fill in the fields or does it allow abstraction where the programmer specifies a few parameters and the appropriate fields are filled in to fulfill the requirements the programmer specified.
>

How would a mere mortal know any of that?

-- gil

[Jon Perryman]

> Dave Wade wrote:
> https://www.theregister.co.uk/2018/01/23/serverless_exhilarating_terrifying_ridiculous_name/
> shows the futility of this discussion.

This is too funny. You may recognize "serverless" by it's common name "The Cloud". Read the wiki for "cloud computing" and you will quickly realize that is a z/OS complex. It must have been an IBM'r who wrote the specifications. After a few years, the specifications had to be relaxed because Unix was never going to meet the specs. Only z/OS could meet them.

Cloud implementations SaaS, PaaS, FaaS and other "as a Service" implementations. Programs must complete these structures and transmit them. Alternatives are Peoplesoft, SAP and other standalone type of products. These cloud implementations are a lot of work to maintain.

z/OS offers an exceptional cloud environment. Easy provisioning(SMS & RMF), easy security(RACF & sysplex complex), networking(SYSPLEX, TCP & SNA), scalability and elasticity (DFHSM, moveable dasd, moveable CPU, CICS, JES, IMS and much more).


IBM made a huge mistake by not z/OS as the cloud without the all the work. Unix is loosely coupled so setting up, managing, maintaining and diagnosing problems are a huge challenge. There are many disparate technologies that must be configured to work together.

It boggles the mind why any company would not choose z/OS because of it's cloud ready.

> Dave wrote: So in terms of new systems the world has moved on. The old world still exists,

Actually, in terms of new systems, the world has moved backwards. Unix is a world of disparate free technologies that are not harmonious. 10 steps forward because Unix is open and you can do anything. 20 steps back because it's open and a lot of work. Just compare programmers responsibilities and you will see MVS programmers know their area of expertise where as Unix programmers are computer specialists.

Jon.

[Jon Perryman]

On Friday, January 26, 2018 7:05 PM, Paul Gilmartin <00000014e0e4a59...@LISTSERV.UGA.EDU> wrote:


> Paul wrote: Does DCB provide functionality not available via DYNALLOC?
DCB is all about the program. There are multiple access methods that can be used (e.g. bsam, qsam). Each may require different parms and tells open/read/write how it wants to deal with the file. For example are you reading sequentially or reading CKD.

DD's (JCL and DYNALLOC) contain information that overrides information in the DCB.


MVS 3.8J was written in PL/S (I think). At that time, IBM was coding DCB in assembler because it was far more maintainable than coding it in PL/s.

So my question is how would DCB AM=BSAM,RECFM=FB be coded (hypothetically) in a PL/S (even if it did not actually exist).
Jon.

[Binyamin Dissen]

On Sat, 27 Jan 2018 05:13:36 +0000 Jon Perryman <jper...@PACBELL.NET> wrote:

:>On Friday, January 26, 2018 7:05 PM, Paul Gilmartin <00000014e0e4a59...@LISTSERV.UGA.EDU> wrote:

:>> Paul wrote: Does DCB provide functionality not available via DYNALLOC?
:>DCB is all about the program. There are multiple access methods that can be used (e.g. bsam, qsam). Each may require different parms and tells open/read/write how it wants to deal with the file. For example are you reading sequentially or reading CKD.

:>DD's (JCL and DYNALLOC) contain information that overrides information in the DCB.

Not at all. DCB overrides all.

--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

[Jon Perryman]

> Paul Raulerson wrote: I think it can be argued that the

> c library provides a complete, and easily extended or
> modified equivalent of HLASM macro processing.

Sorry but I've shown time and again this is not possible for C. In a previous post, I showed XML parse use in pseudo C logic and in an assembler program. The C program is not programmer friendly for these types of situations.

> Paul Raulerson wrote: But the most probably truth is that C is
> far more efficient to program in than HLASM.For simple problems, unquestionably C is the choice (e.g. adding 1 to a variable).

For large complicated problems, assembler is the language of choice. E.g. compare the implementation for I/O. Assembler allowed us to use a robust family of I/O handling compared to Unix streams. Case in point is IBM C open( ) was not close to assembler open with DCB. XML parser is another example. If you believe it's possible, show us a small snippet that demonstrates it's possible.

> Paul Raulerson wrote: for (x=0; x< 100000000; x++) { c++; }

> and optimized it during compile time.

There are certainly features that would be nice in ASM but a good optimizing language doesn't make up for a language that encourages good coding practices (e.g. XML parse).

Jon.

[Paul Raulerson]

> — gil

Probably not - in C someone would simply modify or extend the standard library open() and open() calls to do what is needed for the platform. (Essentially what AIX services do on OS/390 and above…)

We did something similar under Linux with HLASM reading a proprietary filesystem under Linux - the OPEN Macro for instance, just choses what open function to use based upon the DCB information. Same with READ, WRITE, CLOSE, etc. It’s easy and elegant.

This is a funny area to compare though, since on most platforms, C file access is always a binary stream. The application pretty much defines the way the file is treated - byte by byte, record by record, block by block, buffer size by buffer size, etc. To load an image for instance, it is pretty common to fstat() the image file to get its size, malloc() a buffer of the appropriate size, then do a single read() or fread() to populate the buffer. It is extremely efficient on most platforms, often due to the OS buffering.

But it does not equate all that well to traditional mainframe thinking. I mean, under UNIX, if you fread() a byte or so too much from a file, you simply put the extra back on the file. :)

[Eric Chevalier]

On 1/28/18 12:35 AM, Paul Raulerson wrote:
> This is a funny area to compare though, since on most platforms, C
> file access is always a binary stream. The application pretty much
> defines the way the file is treated - byte by byte, record by record,
> block by block, buffer size by buffer size, etc. To load an image for
> instance, it is pretty common to fstat() the image file to get its
> size, malloc() a buffer of the appropriate size, then do a single
> read() or fread() to populate the buffer. It is extremely efficient on
> most platforms, often due to the OS buffering.

Going even further, many platforms allow a file to be mapped into an
application's address space. I work with an unmanaged C++ Windows
application that does CreateFile() to open a file, GetFileSize() to get
the size of the file and then CreateFileMapping() to map the file into
the app's address space. At that point, the app doesn't need any I/O
functions to process the file, it just accesses the contents as memory
and lets the paging system handle the I/O. (And I think we like to
believe that most operating systems go to great lengths to optimize
paging logic.) *nix platforms have mmap() to provide similar functionality.

[Paul Gilmartin]

On 2018-01-27, at 13:03:48, Binyamin Dissen wrote:

> On Sat, 27 Jan 2018 05:13:36 +0000 Jon Perryman wrote:

>
> :>On Friday, January 26, 2018 7:05 PM, Paul Gilmartin wrote:
>
> :>> Paul wrote: Does DCB provide functionality not available via DYNALLOC?
> :>DCB is all about the program. There are multiple access methods that can be used (e.g. bsam, qsam). Each may require different parms and tells open/read/write how it wants to deal with the file. For example are you reading sequentially or reading CKD.
>
> :>DD's (JCL and DYNALLOC) contain information that overrides information in the DCB.
>
> Not at all. DCB overrides all.
>

I believe that the OPEN exit can override options coded in DCB.
And, finally, SDB has a chance to fill in a remaining blank.

But I believe there are constructs available in JCL DD that
don't exist elsewhere. Referback comes to mind.

And I believe there's no way to specify a DSN in a DCB, as is
possible with DYNALLOC.

-- gil

[Binyamin Dissen]

On Sun, 28 Jan 2018 10:16:51 -0600 Eric Chevalier <et...@TULSAGRAMMER.COM>
wrote:

You are referring to a LDS.

[Binyamin Dissen]

On Sun, 28 Jan 2018 09:40:55 -0700 Paul Gilmartin
<00000014e0e4a59...@LISTSERV.UGA.EDU> wrote:

:>On 2018-01-27, at 13:03:48, Binyamin Dissen wrote:

:>> On Sat, 27 Jan 2018 05:13:36 +0000 Jon Perryman wrote:

:>> :>On Friday, January 26, 2018 7:05 PM, Paul Gilmartin wrote:

:>> :>> Paul wrote: Does DCB provide functionality not available via DYNALLOC?
:>> :>DCB is all about the program. There are multiple access methods that can be used (e.g. bsam, qsam). Each may require different parms and tells open/read/write how it wants to deal with the file. For example are you reading sequentially or reading CKD.

:>> :>DD's (JCL and DYNALLOC) contain information that overrides information in the DCB.

:>> Not at all. DCB overrides all.

:>I believe that the OPEN exit can override options coded in DCB.

That is code, not an overriding definition.

:>And, finally, SDB has a chance to fill in a remaining blank.

:>But I believe there are constructs available in JCL DD that
:>don't exist elsewhere. Referback comes to mind.

Yes. And DYNALLOC has options not available in JCL, such as return DDNAME.

:>And I believe there's no way to specify a DSN in a DCB, as is
:>possible with DYNALLOC.

Correct.

[Paul Raulerson]

Like a Master Catalog? Yep- same kind of idea. More widely used under *nix I think.

Typos courtesy of my iPhone and my fat fingers!

> On Jan 28, 2018, at 12:53, Binyamin Dissen <bdi...@DISSENSOFTWARE.COM> wrote:
>
...
...
...

[Jon Perryman]

> Paul Raulerson wrote:

> This is a funny area to compare though, since on most platforms, > C file access is always a binary stream. The application pretty > much defines the way the file is treated - byte by byte, > record by record, block by block, buffer size by buffer > size, etc. To load an image for instance, it is pretty common > to fstat() the image file to get its size, malloc() a buffer of the > appropriate size, then do a single read() or fread() to > populate the buffer. It is extremely efficient on most platforms, > often due to the OS buffering.

> But it does not equate all that well to traditional > mainframe thinking.  I mean, under UNIX, if you fread() a byte > or so too much from a file, you simply put the extra back on the file. :)

C has adversely impacted the world. Most languages have modeled there I/O off of C's I/O (streams). Streams and databases are the most prevalent I/O methods in the world. C programmers are correct in that they CAN do MVS style I/O. The problem is they DON'T because it's too complicated in C style languages. If they truly understood MVS I/O, they would never say "extremely efficient on most platforms".
Consider the C major innovations over 50 years: NFS (1984), block locking, and databases. Block locking has mainly been used for databases because it's too complex for the average programmer.  NFS is Unix's concept of shared dasd it has the same problems as regular files.
Typical C programmer reads or writes a file (nothing sophisticated). C has record locking but it requires programmer to do record processing. C programmers can update a file but most don't. Sophisticated requires using SQL and databases.
Typical Cobol programmer does not even consider SQL and databases because they can do it from standard I/O. More important is the programmer does nothing different or unusual. E.g. open for update.
Consider the major MVS I/O innovations due to records and blocks. There are many and it's difficult to name them all.  VSAM eliminated some of the need for a database. Record locks. I/O queue management. Transactional VSAM eliminated more database requirement. 
There are so many innovations in MVS I/O and the programmer rarely notices anything. To start with, the innovations mentioned above. HSM (disk full). Record insert. 
How about creating efficient programmers. C programmers often don't plan for a record. C have several commands to write and read data from a file. C programmers often must read each field to find the start of the next record (unless they planned for it). If a cobol programmer only needs 2 bytes of a variable length record, they don't need to skip each field.
Much of these innovations exist because HLASM was flexible enough to encourage their development. Anyone who doubts the significance of HLASM is very naive because nothing like these were ever developed in C.
Regards, Jon. 

[Seymour J Metz]

"fstat() the image file to get its size"

What if it isn't an image file, or any other kind of DASD file. Unix has other kinds of files for which there is no way to know the size a priori.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Paul Raulerson <paul.ra...@ME.COM>

Sent: Sunday, January 28, 2018 1:35 AM

To: ASSEMBL...@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM

[Seymour J Metz]

"Does DCB provide functionality not available via DYNALLOC?"

Apples and oranges; they do different things. Don't confuse the DCB macro with things that override DCB parameters. The DCB macro certainly has options that are not relevant to JCL or to dynamic allocation, whether via DAIR, via BPXWDYN or directly via SVC 99, e.g., MACRF. Likewise the have options that are not relevant to the DCB macro.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Paul Gilmartin <00000014e0e4a59...@listserv.uga.edu>
Sent: Friday, January 26, 2018 10:05 PM

To: ASSEMBL...@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM

[Bernd Oppolzer]

Sorry, but you are mixing up things in a somehow a-historic manner,
which needs some corrections:

Databases were invented in the mid to late 1970s at IBM (System R, later
SQL/DS, later DB2), and the first database systems were implemented in
PL/1 on the mainframe, and this has nothing to do with C at all. The idea
behind this development is not to do physical reads on files any more,
but to have a language (SQL) that tells the database system what result
is wanted, and let the database care about the physical access path.
It's not about a "physical" replacement of VSAM in the first turn, but
about
a complete different thinking, for example: have the database system
doing the combination of different "tables" using join operations, grouping
and sorting etc. and keep this logic out of the application program.
This is the key principle of database programming. And very important:
with SQL you tell the system the desired result, but you don't tell the
method how the database produces this result (or the sequence of the
steps); this is left completely to the database system.

BTW: you can very easily use DB2 with ASSEMBLER programs, this has NOTHING
to do with the language. And it's great fun.

And: on the mainframe, you can use C perfectly to access OS files
(aka MVS datasets). The C runtime has some wonderful extensions
which allows the C programmer on the mainframe to do all the things
that an ASSEMBLER programmer can do, and more. For example, it is
very easy to open a file by specifying a DD name OR a DSN; the C
runtime does the dynamic allocation. Same goes for members etc.,
when the member name is known at runtime only ... etc. etc.

Again, you are mixing up things, because the MVS file system and
its merits (or pitfalls) has nothing to do with a particular language.

The differences in file handling come from the different platforms
we use today (Windows, Unix, Mainframe etc.). These differences
can be discussed, of course (no equivalent to physical records on
Windows etc.),
but this has nothing to do with C. C has quite good support for physical
records
on z/OS etc.; the needed functions are part of the ANSI function set
(some specific extensions needed for the correct handling of
binary records of varying length, because such a format doesn't
exist on Windows etc.).

HTH, kind regards

Bernd

[Eric Chevalier]

On 1/28/18 2:31 PM, Seymour J Metz wrote:
> "fstat() the image file to get its size"
>
> What if it isn't an image file, or any other kind of DASD file. Unix has other kinds of files for which there is no way to know the size a priori.

Pedantically speaking, you're correct. However, I don't lose any sleep
over that fact. The code I mentioned is encapsulated in a subroutine
that's not visible outside of the application. Higher level callers to
this routine make sure that the item is capable of being fstat()'d.

[Jon Perryman]

>>> Eric Chavalier wrote: Going even further, many platforms allow a file to be mapped into an

>>>application's address space. I work with an unmanaged C++ Windows
>>>application that does CreateFile() to open a file,

>> Binyamin Dissen wrote: You are referring to a LDS.

> Paul Raulerson wrote: Like a Master Catalog? Yep- same kind of idea. More widely used under *nix I think.

This demonstrates the biggest flaw in Unix and how detrimental this mentality can be. Unix is about what I must know and MVS is not being aware of. Think about the terms "do anything he wants to optimize" and "more widely used". This bugs me more than the problems we discussed with C.

It's great that Eric was able to use createfile for instorage files. As a programmer, it's great that he code whatever he feels makes his program great (in this case optimize). Is this in the business's best interest?

Unix programmers can tell you about thousands of features that are "more widely used on *nix". These features are widely known and the programmers can easily implement in their program. Are they really implementing in the business's best interest?

MVS programmers are in awe when they hear about these Unix features and will quickly tell a Unix programmer they wish they had that (e.g. createfile).

MVS programmers are often totally unaware that these features exist or when they are using them. Case in point is Unix createfile. As Binyamin stated, one of the MVS equivalents would be LDS. There is not a single programmer that knows about (or has any need to know about) LDS. I hear "more widely used" so often. How can anyone guess stats about features that are so well hidden.

Ask any MVS programmer about the actual file used in their program (QSAM, BSAM, KSDS, RRDS, ESDS, LDS, RECFM, LRECL, BLKSIZE, Local shared resources and ...). They may make a guess but it could easily be wrong. Without changing their programs, the data could be QSAM and tomorrow VSAM. A cobol programmer that has "file access is key" would say it must be KSDS but they could be wrong. MVS has subsystem datasets where developers can provide data from any source as a file. They are only limited by their imagination (e.g. random number generator, TCP, database or ???)


IBM (B stands for business) focuses on the business's best interest. Look at all the features we hide from programmers. Recovery of a file (HSM), disk full (HSM), "The Cloud" functionality (CICS, IMS, shared dasd, JES, ...). Programmers get so much functionality with a small learning curve. More time to keep up on their area of expertise.

Unix is a case of motivated reasoning. People want to use it because they get to do so much (e.g. createfile). Other than $$$$, how could any business justify choosing Unix over MVS. $$$$ is usually the deciding factor but you get what you pay for.

Regards, Jon.

[Ze'ev Atlas]

Jon wrote:MVS programmers are in awe when they hear about these Unix features and will quickly tell a Unix programmer they wish they had that (e.g. createfile).

So let me add my two cents to the discussion:In Unix (and Windows,) you have to know where is your file.  In MVS, utilizing system catalog and farther, utilizing DFSMS you don't care.  You basically say "System System on the wall, please bring me my file" and automagically, your file appears!  (even if it was stored on a third level storage).  You basically cannot implement that in Unix.
When I explain that feature, slowly, verrrrrry slowly, so that the Unix programmer would understand the concept and than the idea would sink in and than he or she would have time to process, than they are in awe!
I have more pet peeves but this is the one that I miss the most!
Ze'ev Atlas

[Steve Thompson]

One would be by reading a manual or two of the MVS world.

And if one wrote in PL/?, there are commands to drop directly
into ALC and come back (so I'm told, was never allowed access to
PL/S, PL/AS, or PL/X).

A DCB, going back to a prior post (don't remember by whom), does
not have to have every field "defined". That is, one can do a
GETMAIN or whatever in "C" and init it to nulls and then fill in
those fields that one needs. Then issue OPEN against that DCB and
the system will fill in everything else. It will even put in the
address of the read or write routine (GET/PUT, etc.).

Now, if you did it one way, you got QSAM, if another, you got
BSAM, or BDAM, or ISAM (which is no longer supported by IBM),
etc. But NOT VSAM. That requires an ACB as does VTAM.

One does not need HLASM to this. We used to do this with the old
"F" assembler.

And then with DCB, why not DTFxx from DOS/VS? systems. A bit
lower level in what it does, but there are manuals for this too.

Here is the difference between the DOS and MVS worlds: DOS was
device dependent (DTFxx for Cards, Printer, Sequential DASD,
TAPE, ISAM, etc.) and also had to know the format of the data
(Undefined, Fixed, Fixed Block, Variable, Variable Block, etc.).

Let's talk High Level Languages: COBOL does a lot of stuff that
the programmer just doesn't have to know. Comparing that to "c"
is a mistake!

The problem with "c" is that it does not have a defined set of
I/O verbs in the language def that then gets handled by some
predefined routine for that architecture wherein it is being
compiled.

But, we do have "verbs" defined for ALC in the form of Macros
that generates the code to get to the system provided routines.

And as I recall, the system wherein "c" was developed was a
system for handling "telemetry" from C/O Switches (Phone Company
Central Office switches) for doing switch control and billing. So
a sequential string oriented system was the way things were done.

It turned out that MVS/ESA was *so* needed by PACBELL one would
think it had almost been written for them. Back in those days
(1990ish) it was taking them more than 30 days to do billing for
a set of Central Offices (CO) (problem of the Telco's own design
because of ZUM vs. how things were done around Washington DC ---
Long story on that)

So with being able to load a data space, multiple simultaneous
C/O Billing runs could be done and share the big CO-CO billing
table.... Sorry, this was so long ago I'm forgetting many of the
details on this. But they presented it at a NaSPA local chapter
in the Silicon Valley Area (SPANC, SysProgrammers Association of
Northern California IIRC) at the Boole & Babbage offices right
down the street from Amdahl.

I think you are trying to compare a base ball bat to a mechanical
pencil.

Just my observation. And I do not consider myself to be a c
programmer. Frankly, I can't get past its obtuse pointer handling.

Regards,
Steve Thompson

[Jon Perryman]

> Databases were invented in the mid to late 1970s

> at IBM (System R, later SQL/DS, later DB2)

IMS and Codasyl were invented in 1960's.

> the first database systems were implemented in PL/1 on the mainframe

Since I've never seen source code, I can't say for sure but I suspect that IMS and DB2 were most likely written in PL/S and ASM. Without the IMS and codasyl experience, the different technologies and advancements would have been delayed by many years.

> The idea behind this development is not to do
> physical reads on files any more,

> but to have a language (SQL) with the desired results

I think the idea behind databases is to more effectively access data. Databases and SQL still have the record concept (fields in table) and records are still read in a sequential method. Files have the record as a single piece and require the programmer read the entire record even when they only needed one field. Databases allow records to be broken into pieces allowing the DB admin to structure elements of that record in a more efficient to use method. SQL allows the programmer to interface with the database using all the features provided by the database. If the database was designed correctly, this could substantially reduce resource usage.

> It's not about a "physical" replacement of VSAM in
> the first turn, but about a complete different thinking

More often even with the overhead, VSAM will suffice. Actually, VSAM and databases have commonality. It's not about replacement. It's about balancing simplicity with complexity. A database such as DB2 can give the programmer a lot of flexibility but this comes with complexity. In an ideal world, every dataset would be in a database. In reality, there is no way a DB admin could deal with that many databases. DB admin must analyze data and remain current to the data requirements.

> And: on the mainframe, you can use C perfectly to access OS files

I agree that IBM did a good job with IBM C. Since using these features means the program is not portable, then the choice comes down where you can best solve the problem.

> Again, you are mixing up things, because
> the MVS file system and its merits (or pitfalls) has
> nothing to do with a particular language.

Actually, I'm not mixing it up. Look at the history of systems built with C versus systems built with HLASM. They are dramatically different because C had to settle with language limitations.

> The differences in file handling come from

> the different platforms. but this has nothing to do with C.

> C has quite good support for physical records on z/OS etc.;

Cobol has quite good support too and it is at compile time. This has everything to do with C. C as an application programming language is as good as cobol. As a system language, it simply does not meet the needs of MVS. In 50 years, how has C improved file I/O? *nix is a hodgepodge of low-value technologies that make *nix acceptatable. E.g. createfile has a high value to Unix but compared to LDS is pitiful. It's not much better than VIO

C uses the HLASM api for file handling. My point is that implementing MVS file handling in C would be a nightmare. I don't know anyone that would attempt a small part in C (e.g. DCB). There's a reason MVS file handling does not exist in Unix.


Thanks, Jon.

[Paul Gilmartin]

On 2018-01-28, at 18:55:32, Steve Thompson wrote:

> On 01/26/2018 10:05 PM, Paul Gilmartin wrote:
>> On 2018-01-26, at 19:20:02, Jon Perryman wrote:
>>>>
>>>> Paul Gilmartin Wrote: Isn't a PL/X flavor of DCB provided?
>>> There may be DCB in PL/X. The DCB has many fields to be filled in. Does PL/X require you simply fill in the fields or does it allow abstraction where the programmer specifies a few parameters and the appropriate fields are filled in to fulfill the requirements the programmer specified.
>>>
>> How would a mere mortal know any of that?
>
> One would be by reading a manual or two of the MVS world.
>

Please provide a link to a PL/X reference manual that I, a mere
mortal may read.

-- gil

[Jon Perryman]

> Ze'ev wrote:
> You basically say "System System on the wall,
> please bring me my file" and automagically, your
> file appears! (even if it was stored on a third
> level storage). You basically cannot implement that in Unix.

This is totally possible and easy to create using a virtual file system. I never said you can't do many of the things we do in MVS. I said most people are not willing to do these things properly in the Unix land of the free. The programming is the least of the problems. To build an integrated solution, the developer has the massive task of coordination with groups that are very bureaucratic. At what point will the developer give in and create according to the norm instead of how it really should be.

"portability" is a joke. If you want to make an integrated system product, forget about it. There aren't many system exits. Asking for a system change (kernel) is nearly impossible because there is several *nix groups (e.g. linux, unix, solaris, MVS USS and more). You most likely will need some agreement with other product groups that are supposed to integrate with your product. It only takes disagreement in one of these groups and you start all over again. This is too daunting. Eventually, you come up with some half acceptable solution otherwise you get stuck in a never ending loop.

MVS is littered with useful exit points. Something as simple as security is a common exit point. Look a webserver and you will see they have different security implementations. Most Unix systems are open source and you can add what you want. Exits are a much better idea even when they can't cover every possible problem.

Fortunately Unix is a very light weight OS (e.g. file handling). Portability is for application programmers. While C programmers will say they built system programs (e.g. system utilities - grep, regexp), the reality is it's a glorified application. Application programming is fine because you don't need to rely on approvals and concensus.

Regards, Jon.

[Pieter Wiid]

Hierarchical databases (IMS) was released in 1968. I suspect IDMS (network DB) was not far behind.

Pieter

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Bernd Oppolzer
Sent: 28 January 2018 23:47
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM

[Bernd Oppolzer]

Sorry, I forgot about that,
because in my today's practical experience
only relational databases still matter, so I simply
left the other DB models out. My mistake ...

System R was implemented in PL/1, at least most
parts of it (or at least the early variants which were
used to test the concept). This should have been in the
1975 era. Later versions and esspecially DB2 for MVS
may have been rewritten in PL/S or PL/X or how it's called ...

http://db.cs.berkeley.edu/cs262/SystemR-annotated.pdf

Kind regards

Bernd

Am 29.01.2018 um 07:17 schrieb Pieter Wiid:
> Hierarchical databases (IMS) was released in 1968. I suspect IDMS (network DB) was not far behind.
>
> Pieter
>
> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of Bernd Oppolzer
> Sent: 28 January 2018 23:47
> To: ASSEMBL...@LISTSERV.UGA.EDU
> Subject: Re: Fair comparison C vs HLASM
>
> Sorry, but you are mixing up things in a somehow a-historic manner, which needs some corrections:
>
> Databases were invented in the mid to late 1970s at IBM (System R, later SQL/DS, later DB2), and the first database systems were implemented in

> PL/1 on the mainframe ...

[Bernd Oppolzer]

Just for completeness, and because it could be interesting for
the original topic of the discussion:

DB2 LUW (for Linux, Unix, Windows) is completely written in C,
in IBM's Toronto Lab, that is: different code base, but same DRDA
interface seen from outside. Both developments managed by the
same division inside IBM. This is another example of systems related
software written in C (on other platforms) and in PL/S or PL/X (on the
mainframe).

Kind regards

Bernd

[Steve Thompson]

My apologies, I read the question relative to MVS I/O, not PL/X
which is NOT available outside of IBM (as I was given to
understand as a contractor working on AI Languages in the early
1990s).

I was only allowed to read the output from PL/?, not the source,
except for when reading macros where the PL/? source is embedded
in the macro.

I am just another person who would be very interested in a PL/?
compiler for ISVs and other customers of IBM.

Regards,
Steve Thompson

[Peter Relson]

<snip>

>> I wrote: Writing those in PL/X would have make MVS unmaintainable.
> Peter Relson wrote: The second sentence is untrue,
Peter, it would be interesting to see how PL/X has solved abstract coding
techniques. I know DCB is not written in PL/X. Could you show us a short
snippet of how you would implement this logic in PL/X?

</snip>

I do not recall what the logic was. I was responding to "unmaintainable".
The logic is not relevant. And there is a DCB macro available to PL/X
users. But that is unimportant. PL/X provides the programmer access to
assembler, and to machine constructs. If you can do it in assembler, you
can do it in PL/X (even if "do it in PL/X" might be "tell PL/X exactly
what assembler to use").

<snip>
> Peter Relson wrote: Not that I'm a fan of C but I'm surprised
> just about none of the comments have mentioned metal C

For this topic, it doesn't matter whether it's C or Metal C.
</snip>

Sure it does. Because Metal C gives you access to assembler and to the
IBM-provided assembler executable macros. And that is what is being talked
about.

Peter Relson
z/OS Core Technology Design

[Jonathan Scott]

Ref: Your note of 29 January 2018, 07:49:23 -0500

Someone wrote:
> For this topic, it doesn't matter whether it's C or Metal C.

From z/OS XL C/C++ V2.1.1, you can embed inline assembly instructions in
C/C++ programs without having to use Metal C, and those instructions can
include system macros.

The C/C++ compiler invokes HLASM (at APAR level PI21235 or above) to
assemble a source file containing all of the fragments, with the source
provided in main storage and the binary object code returned in main
storage (using HLASM exits), then the binary code fragments are embedded
at the appropriate points in the C object code.

There are various restrictions, in that for example no relocatable
address constants are allowed, but macros are allowed. Each inline code
fragment is defined to HLASM as a separate CSECT (which makes it easy to
pick out the binary code for that fragment from the overall object
output, and also reduces the risk of assembly-time dependencies between
separate fragments).

I don't consider it a very programmer-friendly environment, but it does
mean that in theory any hardware function or software interface that you
could access in HLASM can also be accessed in C/C++ without having to
use Metal C or call a separate HLASM subroutine.

Jonathan Scott
HLASM, IBM Hursley, UK

[Charles Mills]

> you can embed inline assembly instructions in C/C++ programs

@Jonathan, in C programs only, not C++ -- correct?

Charles

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
On Behalf Of Jonathan Scott
Sent: Monday, January 29, 2018 6:09 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Fair comparison C vs HLASM

[Seymour J Metz]

While the DOS I/O was very device dependent, there was the DTFDI with limited device independence.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Steve Thompson <ste...@COPPER.NET>
Sent: Sunday, January 28, 2018 8:55 PM
To: ASSEMBL...@listserv.uga.edu

Subject: Re: Fair comparison C vs HLASM

[Seymour J Metz]

WTF? IMS was well before the 1970's, to say nothing of the database for SABRE. Outside of IBM there was at least one database on GCOS (nee GECOS).

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________

From: IBM Mainframe Assembler List <ASSEMBL...@listserv.uga.edu> on behalf of Bernd Oppolzer <bernd.o...@T-ONLINE.DE>
Sent: Sunday, January 28, 2018 4:47 PM

To: ASSEMBL...@listserv.uga.edu
Subject: Re: Fair comparison C vs HLASM

[Paul Gilmartin]

On 2018-01-29, at 11:55:56, Seymour J Metz wrote:

> While the DOS I/O was very device dependent, there was the DTFDI with limited device independence.
>

Insofar as "device independence" means restricting every device
type to the capabilities of a card reader/punch.

CMS is similarly limited. Pipelines adds some flexibility.

-- gil

[Charles Mills]

And DTFCP with even more ...

Charles


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]