>> Jon Perryman wrote: >> For this topic, it doesn't matter whether it's C or Metal C.
> Peter relson wrote: > 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. Both C and Metal C allow imbedded assembler thru the same interface. It's unpleasant and designed to discourage it's use. Metal C made functions statically call, eliminated a several standard C functions and added a few functions for commonly used system functions (to avoid coding assembler). There may be other differences but those are what I noticed. > Peter Relson wrote: > I do not recall what the logic was. I was responding to "unmaintainable". > The logic is not relevant. logic is very important to writing "maintainable" code and there here are several examples. Every language has logic that would be unmaintainable. HLASM is the only language that I've seen which is extendable and non-linear. I used DCB as the example but any example showing PL/X is extendable would be great. Maybe something in the following will make it click. Pretend that customers had PL/X. Can you show how you would have reasonly implemented any of these features directly in PL/X? It's not reasonably possible in C. IBM designed ASM as an extendable language to avoid creating new languages for every single component. Sysgen stage1 created JCL from tailoring options specified in the source (nothing to do with ASM). IODEF, CICS config and IMS config (nothing to do with ASM). In PL/X and C, one claim to fame is IF and DO. Using the IBM toolkit, we now have these in HLASM. In PL/X and C, another claim to fame is a=(b+c)*d/e. It is considered much more maintainable than assembler. In assembler (fyi MVS 3.8J for me at the moment), I have extended ASM to allow a similar syntax. I could have implemented that exact syntax but it would require more effort than it's value to me. Just like PL/X & C, Fields can be of different lengths and types. The macro is very simple to write if you precede each operator with a comma, don't honor precedence (process left to right) and don't support parenthesis. Those 3 features would require a lot more code. Some examples using this macro: #calc a,=b,+c,*d,/e #calc a,=(R3) #calc a,=A(b),+c #calc a,+L'b #calc (R2),+L'b I have flag macro's where you don't specify the flag field name. #biton & #bitoff can combine flags from different flag bytes. #TM can only specify flags from the same byte. #biton xxx+yyy+zzz #bitoff yyy+xxx+zzz #TM xxx For IPCS mapping, I have a macro that creates the BLS statements according to the dsect definition. Surprisingly, this macro plus sub-macro's is about 200 lines. The trick is to save opcodes (DSECT, ORG, DC, EQU and one other - can't remember which) and replace the opcode with a macro call. #IPCSDEF , xxxx dsect=yes end CICS and SQL preprocessor. The statements generated by these are far to complicated to implement in C without making language modifications. Could PL/X do this without the CICS or SQL preprocessor? It could easily be implemented in HLASM without a preproccessor. Is there a PL/X or C feature that could not be implemented in HLASM? Thanks, Jon.
