Re: C issue - 'struct stat'
In 6448819105643178.wa.zatlas1yahoo@listserv.ua.edu, on 08/14/2013 at 09:30 PM, Ze'ev Atlas zatl...@yahoo.com said: limited by their sysprogs I would have assumed that the systems programmers would be more interested in PCRE than the applications developers. HFS Do you do anything that won't work with zFS? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In 1324425089-1376535875-cardhu_decombobulator_blackberry.rim.net-1454793260-@b4.c1.bise6.blackberry, on 08/15/2013 at 03:04 AM, Ted MacNEIL eamacn...@yahoo.ca said: NOT set arbitrary rules! Nothing the OP were suggests that the rules were arbitrary, ore even that the systems programmers were the ones making the decision to impose the rules. It is quite common for systems to enforce rules decreed from higher up. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In 520c4685.2070...@gmail.com, on 08/15/2013 at 11:09 AM, David Crayford dcrayf...@gmail.com said: Well said! I've been lucky in that I've never worked at a customer site which had such stupid rules. In fact it's always been the other way round where the application folks had the power. SYSPROGs and service delivery were seen as money spenders, not money makers. Applications and systems are *both* service centers; neither is a money maker. Both are money spenders. Allowing applications to make arbitrary unilateral decision is as bad as allowing systems to make arbitrary unilateral decisions. In both cases, bad decisions impose costs on others. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Shmuel daid: Do you do anything that won't work with zFS? No, fldata treat them the same, so do I. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Bernd wrote shortening the functions' names to 8, upper case characters, COBOL API, etc. I suggest you consider adding #pragma maps for the long function names; if you do this, you don't need to change nothing else. The distribution to classic z/OS is PDS oriented and I was specifically asked to continue that way (I may do parallel USS oriented distro). Any fonction that is a file, becomes a member... 8 characters, upper case, period. If I tell the users to use long, mixed case names, they may do it in COBOL with some compile time parameters... if their sysprog allows them to do it (doubtful). Those who want to do so, may call the internal functions by their long names. For all others, I created an API module. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
It is very late in the day to introduce a new PDS as opposed to PDSE library of this sort. Moreover, while PDSE members must have at most eight-character principal names they may have long aliases. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
bernd wrote Normally, if you compile C sources you got from somewhere on z/OS using the more classical compiler options, this is no problem, unless you have external function names that are longer than 8 characters and that don't differ in their first 8 characters, and for such situations, #pragma map is the perfect solution. For example: #ifdef XML_PRAGMA #pragma map (xml_alloc, XMLXALLO) #pragma map (xml_free , XMLXFREE) I did not know about this pragma. While it would not help me with the need to shorten file names, it wiould have helped otherwise. I will look into it. Thanks ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
It is very late in the day to introduce a new PDS as opposed to PDSE library of this sort. The loadlib and some other libraries are indeed PDSE (I used the word PDS loosly) ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Excellent! Making them PDSEs will decomplicate your life. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Excellent! Making them PDSEs will decomplicate your life. No, it won't. PDSEs are fine and easier to work with then PDSs My main issues were There is no easy way to load members to a library that is defined VB, 255 (IEBUPDTE did not work on that best). I guess I could have used individual steps of IEBGENER. Instead I wrote an ADDMEM utility in Rexx. All other PDS or PDSE manipulation was done using IEBUPDTE or ISPF. Shortening the file names to 8 bytes, upper case consistently in all source code was the core of my port process, but it was done with some Perl scripts. The other core issue was to resolve bind time dependencies. Here I had had the worst headache! I will leave the explanation of my solution out for now until I am ready to publish my process. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
The scheme you have outlined will certainly do the job. It is perhaps more labor-intensive than it needs to be. Recall that while a PDSE member name may be at most 8 of the usual characters in length, an alias of such a member name may be at most 1024 characters in length from an enlarged character set. If then you have a routine name R that is immediately usable as a PDSE member name, you use it. If R is not immediately usable you 1) mangle it to obtain from it a usable PDSE member name M, use M as the member name and 2) specify that R is an alias of M. This scheme also works mutatis mutandis for routines that have multiple entry points E0, E1, . . .; but you have said nothing about such a requirement. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On Wed, 14 Aug 2013 17:14:16 -0500, Ze'ev Atlas wrote: Excellent! Making them PDSEs will decomplicate your life. No, it won't. PDSEs are fine and easier to work with then PDSs My main issues were There is no easy way to load members to a library that is defined VB, 255 (IEBUPDTE did not work on that best). I guess I could have used individual steps of IEBGENER. Instead I wrote an ADDMEM utility in Rexx. All other PDS or PDSE manipulation was done using IEBUPDTE or ISPF. Shortening the file names to 8 bytes, upper case consistently in all source code was the core of my port process, but it was done with some Perl scripts. The other core issue was to resolve bind time dependencies. Here I had had the worst headache! I will leave the explanation of my solution out for now until I am ready to publish my process. You fail to appreciate how much making them UNIX directories could have decomplicated your life. I suspect one of the Dovetailed utilities could let you do a local spawn of a UNIX executable using the unneutered names and propagating DDNAMES. (Or perhaps BPXWUNIX if you eschew third-party utilities.) BTW, when you added PDS capability, etc. to PCRE, I hope you didn't do that at the expense of disabling UNIX directory capability. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
John Gilmore said: Recall that while a PDSE member name may be at most 8 of the usual characters in length, an alias of such a member name may be at most 1024 characters in length from an enlarged character set. If then you have a routine name R that is immediately usable as a PDSE member name, you use it. Very interesting suggestion. I will certainly look into it Thanks ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Paul Gilmartin said: You fail to appreciate how much making them UNIX directories could have decomplicated your life. I suspect one of the Dovetailed utilities could let you do a local spawn of a UNIX executable using the unneutered names and propagating DDNAMES. (Or perhaps BPXWUNIX if you eschew third-party utilities.) No, I don't fail to appreciate this and I've said that I will look into it. The issue is my poor customers who are confined to the Classic z/OS with all what is coming with it, and who are limited by their sysprogs in whatever they can or cannot do (up to the point of not having any say in what compiler option they could or could not use in their COBOL applications.) For them, I will stick with PDS and PDSE. There was at least one person on this forum who had expressed such sentiments and I myself worked in such environments. BTW, when you added PDS capability, etc. to PCRE, I hope you didn't do that at the expense of disabling UNIX directory capability. Please don't underestimate me. You are invited to download my distro and look for yourself. If it is a PDS or PDSE, I deal with it, otherwise, I pretty much continue with the existing code, especially, if it is HFS, I continue with the regular Unix directory related existing code. The current version does not (yet) support file name patterns. There was a limit to my patient for developing new features and I had to decide when to freeze the release. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
are limited by their sysprogs in whatever they can or cannot do (up to the point of not having any say in what compiler option they could or could not use in their COBOL applications.) Their SYSPROGs have too much power! Applications Programmers are there to facilitate the business. So are SYSPROGs! Which means they facilitate apps. NOT set arbitrary rules! - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 15/08/2013 11:04 AM, Ted MacNEIL wrote: are limited by their sysprogs in whatever they can or cannot do (up to the point of not having any say in what compiler option they could or could not use in their COBOL applications.) Their SYSPROGs have too much power! Applications Programmers are there to facilitate the business. So are SYSPROGs! Which means they facilitate apps. NOT set arbitrary rules! Well said! I've been lucky in that I've never worked at a customer site which had such stupid rules. In fact it's always been the other way round where the application folks had the power. SYSPROGs and service delivery were seen as money spenders, not money makers. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On Thu, 15 Aug 2013 03:04:35 +, Ted MacNEIL wrote: are limited by their sysprogs in whatever they can or cannot do (up to the point of not having any say in what compiler option they could or could not use in their COBOL applications.) Their SYSPROGs have too much power! Applications Programmers are there to facilitate the business. So are SYSPROGs! Which means they facilitate apps. NOT set arbitrary rules! I've been on the other side of that one, doing development tools support. For our project, we agreed that our code should be reusable, reentrant, refreshable, running in its own address space, loaded from an authorized library into a nonmodifiable subpool. Each developer could do his own coding and unit testing, but I was charged with the tools for integration. So I made RENT the uniform PARM for assembler, and REUS/RENT/REFR for link editing. Then _one_ developer writing a stand-alone utility chose to make it non-renterable. Not for any functional reason, but only because he chose not to obtain RSA and working storage because It wasn't necessary. I seethed and added the flexibility to our development tools to support one developer's one load module. He cost me more in the support effort than he saved by not coding a GETMAIN. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
I understand. But, that's why there are standards. You backed down when you shouldn't have. My complaint is the dictatorial SYSPROG. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Paul Gilmartin paulgboul...@aim.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 15 Aug 2013 00:16:14 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C issue - 'struct stat' On Thu, 15 Aug 2013 03:04:35 +, Ted MacNEIL wrote: are limited by their sysprogs in whatever they can or cannot do (up to the point of not having any say in what compiler option they could or could not use in their COBOL applications.) Their SYSPROGs have too much power! Applications Programmers are there to facilitate the business. So are SYSPROGs! Which means they facilitate apps. NOT set arbitrary rules! I've been on the other side of that one, doing development tools support. For our project, we agreed that our code should be reusable, reentrant, refreshable, running in its own address space, loaded from an authorized library into a nonmodifiable subpool. Each developer could do his own coding and unit testing, but I was charged with the tools for integration. So I made RENT the uniform PARM for assembler, and REUS/RENT/REFR for link editing. Then _one_ developer writing a stand-alone utility chose to make it non-renterable. Not for any functional reason, but only because he chose not to obtain RSA and working storage because It wasn't necessary. I seethed and added the flexibility to our development tools to support one developer's one load module. He cost me more in the support effort than he saved by not coding a GETMAIN. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 2013-08-14, at 23:29, Ted MacNEIL wrote: I understand. But, that's why there are standards. You backed down when you shouldn't have. But he had blindsided me with a fait accompli. By the time I attempted integration and got the RENT warning from IFOX00, he was able to argue that there were no remaining registers for a working storage base, or plead schedule impact for the required recoding, etc. The memory is too clear. And he's _still_ a co-worker. But he got transferred to Marketing. Of course. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
you wrote: shortening the functions' names to 8, upper case characters, COBOL API, etc. I suggest you consider adding #pragma maps for the long function names; if you do this, you don't need to change nothing else. I simply add an #include file containing the #pragma maps for the function names where I want the names to be changed. That's all. (at least that goes for PL/1 callers, where all the C parameter types can be built, even BYVALUE parameters) Kind regards Bernd Am 09.08.2013 02:44, schrieb Ze'ev Atlas: I thought about what you guys have told me and realized that while you are correct and it is easy to just run the configuration, etc., the work I've done (shortening the functions' names to 8, upper case characters, COBOL API, etc.) is very valuable to those who are still in that environment. And these guys are my intended audience! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Does COBOL support GOFF so you can just use the long names? Seems like a lot of unnecessary work shortening names. Uppercase can be done by the binder UPCASE option. On 10/08/2013, at 5:00 AM, Bernd Oppolzer bernd.oppol...@t-online.de wrote: you wrote: shortening the functions' names to 8, upper case characters, COBOL API, etc. I suggest you consider adding #pragma maps for the long function names; if you do this, you don't need to change nothing else. I simply add an #include file containing the #pragma maps for the function names where I want the names to be changed. That's all. (at least that goes for PL/1 callers, where all the C parameter types can be built, even BYVALUE parameters) Kind regards Bernd Am 09.08.2013 02:44, schrieb Ze'ev Atlas: I thought about what you guys have told me and realized that while you are correct and it is easy to just run the configuration, etc., the work I've done (shortening the functions' names to 8, upper case characters, COBOL API, etc.) is very valuable to those who are still in that environment. And these guys are my intended audience! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On Sat, 10 Aug 2013 07:29:44 +0800, David Crayford wrote: Does COBOL support GOFF so you can just use the long names? Seems like a lot of unnecessary work shortening names. Uppercase can be done by the binder UPCASE option. If this is the upper case option I've encountered, it makes things worse rather than better. BTDT; I must supply MIXED to get things to work. There should never have been such an option as UPPER; MIXED is entirely compatible with the classic Linkage Editor. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
That's the one CASE(MIXED), UPPER is the default. On 10/08/2013, at 7:35 AM, Paul Gilmartin paulgboul...@aim.com wrote: On Sat, 10 Aug 2013 07:29:44 +0800, David Crayford wrote: Does COBOL support GOFF so you can just use the long names? Seems like a lot of unnecessary work shortening names. Uppercase can be done by the binder UPCASE option. If this is the upper case option I've encountered, it makes things worse rather than better. BTDT; I must supply MIXED to get things to work. There should never have been such an option as UPPER; MIXED is entirely compatible with the classic Linkage Editor. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Normally, if you compile C sources you got from somewhere on z/OS using the more classical compiler options, this is no problem, unless you have external function names that are longer than 8 characters and that don't differ in their first 8 characters, and for such situations, #pragma map is the perfect solution. For example: #ifdef XML_PRAGMA #pragma map (xml_alloc, XMLXALLO) #pragma map (xml_free , XMLXFREE) #pragma map (xml_realloc , XMLXREAL) #pragma map (xml_freeall , XMLXFALL) #pragma map (xmlp_open, XMLPOPEN) #pragma map (xml_parser , XMLPPARS) #pragma map (xmlp_outsymbol , XMLPOUTS) #pragma map (xmlp_error , XMLPERRO) #pragma map (xmlp_ftext , XMLPFTXT) #pragma map (xmlp_fehltab , XMLPFTAB) #pragma map (xmlp_listing , XMLPLIST) #pragma map (xmlp_close , XMLPCLOS) #pragma map (xmlp_reparse , XMLPREPA) #pragma map (xmld_serialize , XMLDSERI) #pragma map (xmld_freeNodes , XMLDFRND) #pragma map (xmld_appendNode , XMLDAPND) #pragma map (xmld_deleteNode , XMLDDNOD) #pragma map (xmld_deleteChilds, XMLDDCHI) #pragma map (xmld_deleteAttribs , XMLDDATT) #pragma map (xmld_deleteOneAttrib , XMLDDOAT) #pragma map (xmld_copyNode, XMLDCPND) #pragma map (xmld_parser , XMLDPARS) #pragma map (xmld_printNode , XMLDPRND) #pragma map (xmld_createNode , XMLDCRND) #pragma map (xmld_createAttrib, XMLDCRAT) #endif this way, the linker gets old fashion names which it can handle without problems, and you don't need to do further changes to the C source. Kind regards Bernd Am 10.08.2013 01:35, schrieb Paul Gilmartin: On Sat, 10 Aug 2013 07:29:44 +0800, David Crayford wrote: Does COBOL support GOFF so you can just use the long names? Seems like a lot of unnecessary work shortening names. Uppercase can be done by the binder UPCASE option. If this is the upper case option I've encountered, it makes things worse rather than better. BTDT; I must supply MIXED to get things to work. There should never have been such an option as UPPER; MIXED is entirely compatible with the classic Linkage Editor. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Yes I'm familiar with #pragma map and I use it for CEEBINT LE user exits. It may be preferable to COBOL programmer who prefer 8 char names because of inertia but I personally would prefer to use mixed case long names. On 10/08/2013, at 7:52 AM, Bernd Oppolzer bernd.oppol...@t-online.de wrote: Normally, if you compile C sources you got from somewhere on z/OS using the more classical compiler options, this is no problem, unless you have external function names that are longer than 8 characters and that don't differ in their first 8 characters, and for such situations, #pragma map is the perfect solution. For example: #ifdef XML_PRAGMA #pragma map (xml_alloc, XMLXALLO) #pragma map (xml_free , XMLXFREE) #pragma map (xml_realloc , XMLXREAL) #pragma map (xml_freeall , XMLXFALL) #pragma map (xmlp_open, XMLPOPEN) #pragma map (xml_parser , XMLPPARS) #pragma map (xmlp_outsymbol , XMLPOUTS) #pragma map (xmlp_error , XMLPERRO) #pragma map (xmlp_ftext , XMLPFTXT) #pragma map (xmlp_fehltab , XMLPFTAB) #pragma map (xmlp_listing , XMLPLIST) #pragma map (xmlp_close , XMLPCLOS) #pragma map (xmlp_reparse , XMLPREPA) #pragma map (xmld_serialize , XMLDSERI) #pragma map (xmld_freeNodes , XMLDFRND) #pragma map (xmld_appendNode , XMLDAPND) #pragma map (xmld_deleteNode , XMLDDNOD) #pragma map (xmld_deleteChilds, XMLDDCHI) #pragma map (xmld_deleteAttribs , XMLDDATT) #pragma map (xmld_deleteOneAttrib , XMLDDOAT) #pragma map (xmld_copyNode, XMLDCPND) #pragma map (xmld_parser , XMLDPARS) #pragma map (xmld_printNode , XMLDPRND) #pragma map (xmld_createNode , XMLDCRND) #pragma map (xmld_createAttrib, XMLDCRAT) #endif this way, the linker gets old fashion names which it can handle without problems, and you don't need to do further changes to the C source. Kind regards Bernd Am 10.08.2013 01:35, schrieb Paul Gilmartin: On Sat, 10 Aug 2013 07:29:44 +0800, David Crayford wrote: Does COBOL support GOFF so you can just use the long names? Seems like a lot of unnecessary work shortening names. Uppercase can be done by the binder UPCASE option. If this is the upper case option I've encountered, it makes things worse rather than better. BTDT; I must supply MIXED to get things to work. There should never have been such an option as UPPER; MIXED is entirely compatible with the classic Linkage Editor. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL names was Re: C issue - 'struct stat'
On 9 Aug 2013 17:02:54 -0700, in bit.listserv.ibm-main you wrote: Yes I'm familiar with #pragma map and I use it for CEEBINT LE user exits. It may be preferable to COBOL programmer who prefer 8 char names because of inertia but I personally would prefer to use mixed case long names. Most COBOL programs only deal with things in the classic z/OS data sets which for programs and copy members must have 8 character names. I kept using upper case only when working because of the problem with alpha numeric literals and compares. Limiting data to upper case only probably doesn't cut it any more but it simplifies the compares and allows use of code that generates CLC and CLI. Allowing for lower case and culturally sensitive sorting (dictionary rules apparently differ from telephone book rules) immediately involves complex subroutines. I would have liked subroutine, program and job names at least 15 characters long or the standard COBOL 30 characters but MVS and z/OS get upset with them outside of the Unix world. Clark Morris On 10/08/2013, at 7:52 AM, Bernd Oppolzer bernd.oppol...@t-online.de wrote: Normally, if you compile C sources you got from somewhere on z/OS using the more classical compiler options, this is no problem, unless you have external function names that are longer than 8 characters and that don't differ in their first 8 characters, and for such situations, #pragma map is the perfect solution. For example: #ifdef XML_PRAGMA #pragma map (xml_alloc, XMLXALLO) #pragma map (xml_free , XMLXFREE) #pragma map (xml_realloc , XMLXREAL) #pragma map (xml_freeall , XMLXFALL) #pragma map (xmlp_open, XMLPOPEN) #pragma map (xml_parser , XMLPPARS) #pragma map (xmlp_outsymbol , XMLPOUTS) #pragma map (xmlp_error , XMLPERRO) #pragma map (xmlp_ftext , XMLPFTXT) #pragma map (xmlp_fehltab , XMLPFTAB) #pragma map (xmlp_listing , XMLPLIST) #pragma map (xmlp_close , XMLPCLOS) #pragma map (xmlp_reparse , XMLPREPA) #pragma map (xmld_serialize , XMLDSERI) #pragma map (xmld_freeNodes , XMLDFRND) #pragma map (xmld_appendNode , XMLDAPND) #pragma map (xmld_deleteNode , XMLDDNOD) #pragma map (xmld_deleteChilds, XMLDDCHI) #pragma map (xmld_deleteAttribs , XMLDDATT) #pragma map (xmld_deleteOneAttrib , XMLDDOAT) #pragma map (xmld_copyNode, XMLDCPND) #pragma map (xmld_parser , XMLDPARS) #pragma map (xmld_printNode , XMLDPRND) #pragma map (xmld_createNode , XMLDCRND) #pragma map (xmld_createAttrib, XMLDCRAT) #endif this way, the linker gets old fashion names which it can handle without problems, and you don't need to do further changes to the C source. Kind regards Bernd Am 10.08.2013 01:35, schrieb Paul Gilmartin: On Sat, 10 Aug 2013 07:29:44 +0800, David Crayford wrote: Does COBOL support GOFF so you can just use the long names? Seems like a lot of unnecessary work shortening names. Uppercase can be done by the binder UPCASE option. If this is the upper case option I've encountered, it makes things worse rather than better. BTDT; I must supply MIXED to get things to work. There should never have been such an option as UPPER; MIXED is entirely compatible with the classic Linkage Editor. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
There was a time when there were no fancy compiler options like DLL, RENT, LONGNAME etc., and even then C programs had to be (and could be) ported to the mainframe, and that's the time when I started that business, and #pragma map was my primary option. As long as we are in the C world, everything is fine, because every C source includes a header, which translates the long names into short names (for the linker) by a large list of #pragma map statements - but when other languages try to call us (be it COBOL, FORTRAN, or PL/1), they use the short (8 char) uppercase names. Our C routines are traditional load modules, PDSes, no GOFF or other fancy stuff. Of course, the parameter conventions had to be defined in such a way that the other languages could cope with it. Big fun :-) and that approach is still valid today and used successfully at our site. No need for more modern techniques - and we don't need no DLLs, because we deployed a similar technique ourselves, long before IBM did it. We don't want to migrate ... it works with classical load modules. Kind regards Bernd Am 10.08.2013 02:02, schrieb David Crayford: Yes I'm familiar with #pragma map and I use it for CEEBINT LE user exits. It may be preferable to COBOL programmer who prefer 8 char names because of inertia but I personally would prefer to use mixed case long names. On 10/08/2013, at 7:52 AM, Bernd Oppolzer bernd.oppol...@t-online.de wrote: Normally, if you compile C sources you got from somewhere on z/OS using the more classical compiler options, this is no problem, unless you have external function names that are longer than 8 characters and that don't differ in their first 8 characters, and for such situations, #pragma map is the perfect solution. For example: #ifdef XML_PRAGMA #pragma map (xml_alloc, XMLXALLO) #pragma map (xml_free , XMLXFREE) #pragma map (xml_realloc , XMLXREAL) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On Sat, 10 Aug 2013 03:53:17 +0200, Bernd Oppolzer wrote: There was a time when there were no fancy compiler options like DLL, RENT, LONGNAME etc., and even then C programs had to be (and could be) ported to the mainframe, and that's the time when I started that business, and #pragma map was my primary option. As long as we are in the C world, everything is fine, because every C source includes a header, which translates the long names into short names (for the linker) by a large list of #pragma map statements - but when other languages try to call us (be it COBOL, FORTRAN, or PL/1), they use the short (8 char) uppercase names. Do you feel that way only because it's so tedious to multi-punch those lowercase characters on your 029 keypunch? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 10/08/2013 9:53 AM, Bernd Oppolzer wrote: There was a time when there were no fancy compiler options like DLL, RENT, LONGNAME etc., and even then C programs had to be (and could be) ported to the mainframe, and that's the time when I started that business, and #pragma map was my primary option. As long as we are in the C world, everything is fine, because every C source includes a header, which translates the long names into short names (for the linker) by a large list of #pragma map statements - but when other languages try to call us (be it COBOL, FORTRAN, or PL/1), they use the short (8 char) uppercase names. I'm not being critical of your design. #pragma map is a fine idea. It's just personal preference that I prefer long descriptive names. I also like the consistency that all the functions will have the same name irrespective of the programming language. 8 character names just don't do it for me. I have the same issue with member names which is why I prefer UNIX file systems. Our C routines are traditional load modules, PDSes, no GOFF or other fancy stuff. IIRC, GOFF doesn't require PDS/E. Thank god for that, the C prelinker is not my idea of fun. Of course, the parameter conventions had to be defined in such a way that the other languages could cope with it. Big fun :-) and that approach is still valid today and used successfully at our site. No need for more modern techniques - and we don't need no DLLs, because we deployed a similar technique ourselves, long before IBM did it. We don't want to migrate ... it works with classical load modules. Kind regards Bernd Am 10.08.2013 02:02, schrieb David Crayford: Yes I'm familiar with #pragma map and I use it for CEEBINT LE user exits. It may be preferable to COBOL programmer who prefer 8 char names because of inertia but I personally would prefer to use mixed case long names. On 10/08/2013, at 7:52 AM, Bernd Oppolzer bernd.oppol...@t-online.de wrote: Normally, if you compile C sources you got from somewhere on z/OS using the more classical compiler options, this is no problem, unless you have external function names that are longer than 8 characters and that don't differ in their first 8 characters, and for such situations, #pragma map is the perfect solution. For example: #ifdef XML_PRAGMA #pragma map (xml_alloc, XMLXALLO) #pragma map (xml_free , XMLXFREE) #pragma map (xml_realloc , XMLXREAL) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Am 10.08.2013 05:01, schrieb Paul Gilmartin: On Sat, 10 Aug 2013 03:53:17 +0200, Bernd Oppolzer wrote: There was a time when there were no fancy compiler options like DLL, RENT, LONGNAME etc., and even then C programs had to be (and could be) ported to the mainframe, and that's the time when I started that business, and #pragma map was my primary option. As long as we are in the C world, everything is fine, because every C source includes a header, which translates the long names into short names (for the linker) by a large list of #pragma map statements - but when other languages try to call us (be it COBOL, FORTRAN, or PL/1), they use the short (8 char) uppercase names. Do you feel that way only because it's so tedious to multi-punch those lowercase characters on your 029 keypunch? No, because I don't like to be forced to use the RENT option implied by the DLL option. Our solution is simple, secure and cost-effective, and it makes DLL-like libraries possible even for not LE enabled ASSEMBLER callers etc. - in fact it's a long story, and the target was to integrate the C language into an environment, where the programming languages were only ASSEMBLER and PL/1 until that time, where all calls are dynamic (using MVS LOAD) and all modules are compiled using NORENT and are traditional load modules. Same restrictions apply until today - but we don't feel regard this as a restriction. There was a time from 2003 to 2006, when our PL/1 modules were compiled with the RENT option, because the EP compiler didn't support NORENT first, but due to problems with that (for example: USE COUNT overflow in certain IMS environments), we changed it back to NORENT in 2006. Our C modules were always NORENT. The home grown DLL mechanism (which supports all languages) was developed in 1995, already. It works without problems until today. Kind regards Bernd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In 2883356613158771.wa.paulgboulderaim@listserv.ua.edu, on 08/07/2013 at 08:34 AM, Paul Gilmartin paulgboul...@aim.com said: Alas, IBM developers abandoned this paradigm. One writes to the operator's console not using QSAM, but WTO; one writes to the TSO terminal not using QSAM to SYSTSPRT, but TPUT. Actually, they DTRT in *those* cases, IMHO. Writing to the operator is more than a simple I/O, at least with MCS, and if you open a QSAM DCB with the ddname allocated to the terminal then you can use GET and PUT transparently. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In 00d501ce937a$2c525710$84f70530$@mcn.org, on 08/07/2013 at 10:26 AM, Charles Mills charl...@mcn.org said: You know, IMHO IBM blew it when the 31-bit thing came along and they came up with a bunch of design patches to QSAM like the DBCE. I disagree; I consider the DCB approach superior to file handles. However, I believe that they should have gradually switch everything to an ACB/RPL interface, with CI and RCI to ease the tranistion. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On Wed, 7 Aug 2013 16:43:41 -0400, Shmuel Metz (Seymour J.) wrote: Alas, IBM developers abandoned this paradigm. One writes to the operator's console not using QSAM, but WTO; one writes to the TSO terminal not using QSAM to SYSTSPRT, but TPUT. Actually, they DTRT in *those* cases, IMHO. Writing to the operator is more than a simple I/O, at least with MCS, and if you open a QSAM DCB with the ddname allocated to the terminal then you can use GET and PUT transparently. Ummm... I believe that in a conventional TSO terminal session SYSTSPRT isn't even allocated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In 5499902479450252.wa.paulgboulderaim@listserv.ua.edu, on 08/08/2013 at 11:07 AM, Paul Gilmartin paulgboul...@aim.com said: On Wed, 7 Aug 2013 16:43:41 -0400, Shmuel Metz (Seymour J.) wrote: Alas, IBM developers abandoned this paradigm. One writes to the operator's console not using QSAM, but WTO; one writes to the TSO terminal not using QSAM to SYSTSPRT, but TPUT. Actually, they DTRT in *those* cases, IMHO. Writing to the operator is more than a simple I/O, at least with MCS, and if you open a QSAM DCB with the ddname allocated to the terminal then you can use GET and PUT transparently. Ummm... I believe that in a conventional TSO terminal session SYSTSPRT isn't even allocated. 1. There's nothing special about SYSTSPRT. It's only relevance is that the TMP in batch creates a stack element for the ddnames SYSTSIN and SYSTSPRT. 2. Your JCL determines what is allocated. There's nothing in TSO that allocates any hardwired ddname. 3. You can allocate a ddname to the terminal both in JCL and in dynamic allocation. QSAM doesn't depend on the ddname being SYSTSIN or SYSTSPRT. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
I thought about what you guys have told me and realized that while you are correct and it is easy to just run the configuration, etc., the work I've done (shortening the functions' names to 8, upper case characters, COBOL API, etc.) is very valuable to those who are still in that environment. And these guys are my intended audience! To those who just build the thing in USS, please have a look at my config.h for some things that are not necessarily available otherwise. I hear about ports that are done to other open source (I read MVS-OE as well) and this is encouraging, but I wish that those who do those ports should make their ports (with the z/OS related changes, minor as they could be) available in some way, similar to what I am doing. Thank you all ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On Tue, 6 Aug 2013 12:39:09 +0800, David Crayford wrote: I've always liked the nice abstraction with the z/OS C/C++ FILE I/O implementation. fopen() is a factory function which returns a semi-opaque structure with two function pointers to read/write routines (methods) which handle all the different access methods (QSAM, BSAM, VSAM, UNIX, Hiperspaces etc). It's a good design and an example of OO done well in C using pointers in structs ;). In fact, in Assembler the DCB has much this character. OPEN updates the DCB by adding pointers to the access method entry points. Alas, IBM developers abandoned this paradigm. One writes to the operator's console not using QSAM, but WTO; one writes to the TSO terminal not using QSAM to SYSTSPRT, but TPUT. And I believe I have evidence that FTP given the DD: construct does not Do the Right Thing of OPENing a DCB on that DDNAME, but chases control blocks to suss out the underlying object and performs its own allocation, probably thwarting any attempt of the caller to override attributes, etc. On Wed, 26 Jun 2013 07:33:40 -0400, Shmuel Metz (Seymour J.) wrote: What went wrong? It started early: George Mealy is alleged to have called it The rape of the design integrity of OS/360 and blamed it on a lack of standards enforcement. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 07/08/2013, at 9:34 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 6 Aug 2013 12:39:09 +0800, David Crayford wrote: I've always liked the nice abstraction with the z/OS C/C++ FILE I/O implementation. fopen() is a factory function which returns a semi-opaque structure with two function pointers to read/write routines (methods) which handle all the different access methods (QSAM, BSAM, VSAM, UNIX, Hiperspaces etc). It's a good design and an example of OO done well in C using pointers in structs ;). In fact, in Assembler the DCB has much this character. OPEN updates the DCB by adding pointers to the access method entry points. Shame it doesn't support VSAM. Or maybe ACB should support QSAM, BSAM etc. Alas, IBM developers abandoned this paradigm. One writes to the operator's console not using QSAM, but WTO; one writes to the TSO terminal not using QSAM to SYSTSPRT, but TPUT. And I believe I have evidence that FTP given the DD: construct does not Do the Right Thing of OPENing a DCB on that DDNAME, but chases control blocks to suss out the underlying object and performs its own allocation, probably thwarting any attempt of the caller to override attributes, etc. I prefer the UNIX philosophy where everything is a file. Programming is difficult enough without inconsistent interfaces. On Wed, 26 Jun 2013 07:33:40 -0400, Shmuel Metz (Seymour J.) wrote: What went wrong? It started early: George Mealy is alleged to have called it The rape of the design integrity of OS/360 and blamed it on a lack of standards enforcement. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
You know, IMHO IBM blew it when the 31-bit thing came along and they came up with a bunch of design patches to QSAM like the DBCE. They should have gone the file handle route where the control blocks were hidden from the using programmers. You could continue to use 24-bit DCBs as-is for as long as you liked, but if you wanted anything new you got a pointer to a control block whose exact format was DFSMS's business alone and was subject to change. If you wanted information about the dataset object that it pointed to, you called an API. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Wednesday, August 07, 2013 10:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C issue - 'struct stat' On 07/08/2013, at 9:34 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 6 Aug 2013 12:39:09 +0800, David Crayford wrote: I've always liked the nice abstraction with the z/OS C/C++ FILE I/O implementation. fopen() is a factory function which returns a semi-opaque structure with two function pointers to read/write routines (methods) which handle all the different access methods (QSAM, BSAM, VSAM, UNIX, Hiperspaces etc). It's a good design and an example of OO done well in C using pointers in structs ;). In fact, in Assembler the DCB has much this character. OPEN updates the DCB by adding pointers to the access method entry points. Shame it doesn't support VSAM. Or maybe ACB should support QSAM, BSAM etc. Alas, IBM developers abandoned this paradigm. One writes to the operator's console not using QSAM, but WTO; one writes to the TSO terminal not using QSAM to SYSTSPRT, but TPUT. And I believe I have evidence that FTP given the DD: construct does not Do the Right Thing of OPENing a DCB on that DDNAME, but chases control blocks to suss out the underlying object and performs its own allocation, probably thwarting any attempt of the caller to override attributes, etc. I prefer the UNIX philosophy where everything is a file. Programming is difficult enough without inconsistent interfaces. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On Wed, 7 Aug 2013 10:26:56 -0400, Charles Mills wrote: You know, IMHO IBM blew it when the 31-bit thing came along and they came up with a bunch of design patches to QSAM like the DBCE. They should have gone the file handle route where the control blocks were hidden from the using programmers. You could continue to use 24-bit DCBs as-is for as long as you liked, but if you wanted anything new you got a pointer to a control block whose exact format was DFSMS's business alone and was subject to change. If you wanted information about the dataset object that it pointed to, you called an API. But still, will that be a 24-bit, a 31-bit, or a 64-bit API? UNIX and C benefit from a culture where programmers are willing to recompile in order to exploit new function, and understand the risks of meddling with opaque data objects. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Right you are. Parenthetically, no need for a 24-bit API because the whole point would be to allow QSAM to exploit 32-bit. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, August 07, 2013 10:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C issue - 'struct stat' On Wed, 7 Aug 2013 10:26:56 -0400, Charles Mills wrote: You know, IMHO IBM blew it when the 31-bit thing came along and they came up with a bunch of design patches to QSAM like the DBCE. They should have gone the file handle route where the control blocks were hidden from the using programmers. You could continue to use 24-bit DCBs as-is for as long as you liked, but if you wanted anything new you got a pointer to a control block whose exact format was DFSMS's business alone and was subject to change. If you wanted information about the dataset object that it pointed to, you called an API. But still, will that be a 24-bit, a 31-bit, or a 64-bit API? UNIX and C benefit from a culture where programmers are willing to recompile in order to exploit new function, and understand the risks of meddling with opaque data objects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On Wed, 7 Aug 2013 12:04:51 -0400, Charles Mills wrote: Parenthetically, no need for a 24-bit API because the whole point would be to allow QSAM to exploit 32-bit. Underreacher. While 32-bit may be twice as good as 31-bit, it's not nearly as good as 64-bit. Anyone who designs a new control block with less than 64-bit pointers, even for entry point addresses, is shortsighted. It'll (maybe?) happen someday. Until then, David's factory function can stuff the 64-bit pointers with addresses below-the-bar. Or am I underreaching? If the structure is truly opaque, the programmer shouldn't care (or even know) what size pointers it contains. But the API should be strictly 64-bit (until 128 looms on the horizon -- I understand ZFS is already 128-bit). And even then, the distinction should affect only Assembler programs; HLL programs should just be recompiled with the revised header files. I don't know how strongly Java is committed to 32 GiB address spaces with 32-bit pointers. Flight of fancy: If z/OS were truly well-parameterized, a designer could simply change _one_ whatever EQU 44 to whatever EQU 100 in a mapping macro and recompile the entire OS to get 100-character DSN capability. (We tried something like that with one of our products a couple decades ago. Sure enough, the hardware designers thought of a way to add an enhancement we hadn't parameterized -- something like adding a new dimension to the topology.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Also //DD:ddname and * (SYSOUT=*). Make sure you use the //. Without them you get the expected results with POSIX OFF, but with POSIX ON then fopen(DD:SYSPRINT, ...) believe it or not creates an HFS file named DD:SYSPRINT. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, August 06, 2013 12:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C issue - 'struct stat' On Mon, 5 Aug 2013 20:52:11 -0500, Ze'ev Atlas wrote: For subsequent releases, I may opt for two versions, one with PDS, etc. to accommodate you and the CBT-TAPE crowd, and the other perhaps using the Unix side to get more in sync with the original product and to accommodate sysprogs who might want to install it that way. In any case, I do not intend (and this is pledge!) to abandon the old classic z/OS. fopen() will handle fopen( //'data.set.name(member)' ) and fopen( /UNIX/path/name ) alike. open() only the UNIX path. So if you intend to support Classic data sets you are constrained to use fopen(). Then handling UNIX paths is no additional code. (Of course this constrains your users to those respective syntactic forms. But you need some way of distinguishing the two species, and the C RTL convention is as good as any.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Ze'ev, I would like to chime in and say that you started in exactly the right place for those of us who work where there is no unix file system space regularly made available to application programmers. ISV's and SP's can allocate and populate unix file systems at will, while ordinary application programmers have no authority to perform such allocations. In my experience, SP's who have set up automatic allocation of /u/tsouser unix file system space for application users is not common and requesting it requires a business case, not easily made by a mere application programmer. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ze'ev Atlas Sent: Saturday, August 03, 2013 10:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: C issue - 'struct stat' Why not build the object code for the open source packages using the UNIX file system etc. (and makefile, if you like) I hear you guys and will probably change direction to do it this way. I will go through the documentation and hopefully David will send me some concise explanation that would bring me up to speed. I guess that not all what I did is a waste. For example the COBOL/PLI interfaces, some supporting routines and so on. I also have to see whether I have full access to Unix services. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
I _knew_ I was unusual. I have set up BPX.NEXT.USER and automount on z/OS
UNIX to automatically create a UID and make a ${HOME} for any RACF id which
does UNIX work. Not that any of our programmers actually _use_ UNIX. Or are
even aware that it exists on z/OS. Almost all of the adventurous
programmers have been RIF'd and the few left don't have time to fool
around with irrelevant things like UNIX.
On Mon, Aug 5, 2013 at 9:48 AM, Farley, Peter x23353
peter.far...@broadridge.com wrote:
Ze'ev,
I would like to chime in and say that you started in exactly the right
place for those of us who work where there is no unix file system space
regularly made available to application programmers. ISV's and SP's can
allocate and populate unix file systems at will, while ordinary application
programmers have no authority to perform such allocations.
In my experience, SP's who have set up automatic allocation of
/u/tsouser unix file system space for application users is not common and
requesting it requires a business case, not easily made by a mere
application programmer.
Peter
--
As of next week, passwords will be entered in Morse code.
Maranatha!
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
I would like to chime in and say that you started in exactly the right place for those of us who work where there is no unix file system space regularly made available to application programmers. ISV's and SP's can allocate and populate unix file systems at will, while ordinary application programmers have no authority to perform such allocations. In my experience, SP's who have set up automatic allocation of /u/tsouser unix file system space for application users is not common and requesting it requires a business case, not easily made by a mere application programmer. I hear you Peter and I've been in that situation all along. I also hear all the good things about using 'automated tools' and I probably need to study about them. On the other hand, when I did it the old way (PDS and all), I had to actually go and intervene in the code, which when you have the automated tools you tend not to do. So by doing it my way I've gained some flexibility and also could notice what would not work for the classic system (hence my COBOL API). The coming release (shortly) will definitely be the old way only. I basically finished all the leftover core functionalities that were missing in previous releases, including Posix modules and PCREGREP that could handle PDS and PDSE so I am getting ready to deliver. For subsequent releases, I may opt for two versions, one with PDS, etc. to accommodate you and the CBT-TAPE crowd, and the other perhaps using the Unix side to get more in sync with the original product and to accommodate sysprogs who might want to install it that way. In any case, I do not intend (and this is pledge!) to abandon the old classic z/OS. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On Mon, 5 Aug 2013 20:52:11 -0500, Ze'ev Atlas wrote: For subsequent releases, I may opt for two versions, one with PDS, etc. to accommodate you and the CBT-TAPE crowd, and the other perhaps using the Unix side to get more in sync with the original product and to accommodate sysprogs who might want to install it that way. In any case, I do not intend (and this is pledge!) to abandon the old classic z/OS. fopen() will handle fopen( //'data.set.name(member)' ) and fopen( /UNIX/path/name ) alike. open() only the UNIX path. So if you intend to support Classic data sets you are constrained to use fopen(). Then handling UNIX paths is no additional code. (Of course this constrains your users to those respective syntactic forms. But you need some way of distinguishing the two species, and the C RTL convention is as good as any.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 6/08/2013 12:07 PM, Paul Gilmartin wrote: On Mon, 5 Aug 2013 20:52:11 -0500, Ze'ev Atlas wrote: For subsequent releases, I may opt for two versions, one with PDS, etc. to accommodate you and the CBT-TAPE crowd, and the other perhaps using the Unix side to get more in sync with the original product and to accommodate sysprogs who might want to install it that way. In any case, I do not intend (and this is pledge!) to abandon the old classic z/OS. fopen() will handle fopen( //'data.set.name(member)' ) and fopen( /UNIX/path/name ) alike. open() only the UNIX path. So if you intend to support Classic data sets you are constrained to use fopen(). Then handling UNIX paths is no additional code. I've always liked the nice abstraction with the z/OS C/C++ FILE I/O implementation. fopen() is a factory function which returns a semi-opaque structure with two function pointers to read/write routines (methods) which handle all the different access methods (QSAM, BSAM, VSAM, UNIX, Hiperspaces etc). It's a good design and an example of OO done well in C using pointers in structs ;). (Of course this constrains your users to those respective syntactic forms. But you need some way of distinguishing the two species, and the C RTL convention is as good as any.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
OK guys, you are pulling me kicking and screaming towards Unix and I must admit that there is a point in what you are saying. So I made a decision: 1. In the short term I am already geared towards working with PDS and classic z/OS environment. Also adding PDS functionality to PCREGREP is almost done , so the next release will still be in classic z/OS, PDS and all. 2. In the long term, I will review everything you have suggested and review the documentation carefully and in all likelihood, will follow your suggestions (to the dismay of Sam Golob.) Some note: I just built pcre-8.33 and was impressed by how easy it was build. I ran ./configure --enable-ebcdic amp;amp; make and it built clean straight off the bat. There are still some things that have to be done in the config header beyond ./configure --enable-ebcdic amp;amp and obviously, my code has to be incorporated, including adjustments for COBOL/PLI usage, but I guess that your suggestions are still valid. Oh, and I started using OMVS and I must say that Unix without vi is great because I believe in the following adage: The world of text editor users is divided into three groups, those that believe that vi is God's gift to humanity, those that believe that vi is a bug, not a feature, and those that use ISPF :) ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 4/08/2013 10:04 AM, Ze'ev Atlas wrote: I just built pcre-8.33 and was impressed by how easy it was build. I ran ./configure --enable-ebcdic amp; make and it built clean straight off the bat. I ran the test suite and had a quick look at pcregrep which is significantly more powerful than POSIX grep. It's my first look a pcre and it's great package. OK, this proves to me that I was wrong all along and should have looked that direction from the beginning. In my defense, I am a classic z/OS programmer in the core and all these Unix tools confuse me. Would you be so kind and send me (maybe off the list) a full script of what you are doing including an explanation for Dummies assuming I know nothing! Thanks ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Here's what I did. It's a order of magnitude simpler than rubbing two sticks together with JCL and PDS data sets. Run the following commands from a z/OS UNIX shell (I use putty). You will need to download the UNIX tools that I mentioned before for gzip etc and have ported tools installed if you want to use curl. 1. download PCRE source code tarball curl -O ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.33.tar.gz 2. decompress the package gzip -d pcre-8.33.tar.gz 3. extract the archive converting ASCII to EBCDIC pax -o from=iso8859-1 -rvf pcre-8.33.tar.gz 4. build the software cd pcre-8.33 ./configure --enable-ascii gmake 5. run the test suite RunTest 6. simple pcregrep test pcregrep '#includ' *.cpp Simple as that. Took less than 10 minutes end-to-end. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 4/08/2013 9:59 PM, Paul Gilmartin wrote: On Sun, 4 Aug 2013 16:30:21 +0800, David Crayford wrote: ... 4. build the software cd pcre-8.33 ./configure --enable-ascii amp; gmake ... Simple as that. Took less than 10 minutes end-to-end. Surprising. I never got configure to run in less than 10 minutes under zz/OS Unix. (Much faster on a real UNIX system.) The configure script took less than 3 minutes on our z/114. (What does --enable-ascii do? I thought ZA reported using ENABLE_EBCDIC.) PCRE is already EBCDIC enabled. --enable-ascii just turns on the EBCDIC FTMs. It's always feels like a victory when you stumble across a package that has already done the EBCDIC slog for you. When that package is regular expressions it is so much sweeter. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In 1229979691582383.wa.zatlas1yahoo@listserv.ua.edu, on 08/04/2013 at 12:59 AM, Ze'ev Atlas zatl...@yahoo.com said: The world of text editor users is divided into three groups, those that believe that vi is God's gift to humanity, those that believe that vi is a bug, not a feature, and those that use ISPF While I admit to using an SPF clone[1] on my PC, I believe that emacs is more common. As to vi, it may well be The Editor From Hell, but it is also the only editor that you can count on finding in an arbitrary *ix system. So keep[2] vi. There are also a number of other editors that some people swear by. [1] Tritus SPF [2] Far from me -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 4/08/2013 10:38 PM, Shmuel Metz (Seymour J.) wrote: In 1229979691582383.wa.zatlas1yahoo@listserv.ua.edu, on 08/04/2013 at 12:59 AM, Ze'ev Atlas zatl...@yahoo.com said: The world of text editor users is divided into three groups, those that believe that vi is God's gift to humanity, those that believe that vi is a bug, not a feature, and those that use ISPF While I admit to using an SPF clone[1] on my PC, I believe that emacs is more common. As to vi, it may well be The Editor From Hell, but it is also the only editor that you can count on finding in an arbitrary *ix system. So keep[2] vi. There are also a number of other editors that some people swear by. [1] Tritus SPF [2] Far from me You don't mention Eclipse which is free and has C/C++ editors for free. SMB or NFS mounts make this a piece of cake. I'm a Slickedit user which supports all mainframe languages, even HLASM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In 51fe6a71.2060...@gmail.com, on 08/04/2013 at 10:51 PM, David Crayford dcrayf...@gmail.com said: You don't mention Eclipse There are also a number of other editors that some people swear by. That covers the editors that I didn't mention explicitly, e.g., BRIEF, Kate. I suspect that there are hundreds of editors with dedicated fans. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
I feel so abused. I actually like vim, especially gvim. Once again, I am totally non-main-stream. On Sun, Aug 4, 2013 at 9:51 AM, David Crayford dcrayf...@gmail.com wrote: On 4/08/2013 10:38 PM, Shmuel Metz (Seymour J.) wrote: In 1229979691582383.WA.**zatlas1yahoo@listserv.ua.**edu1229979691582383.wa.zatlas1yahoo@listserv.ua.edu, on 08/04/2013 at 12:59 AM, Ze'ev Atlas zatl...@yahoo.com said: The world of text editor users is divided into three groups, those that believe that vi is God's gift to humanity, those that believe that vi is a bug, not a feature, and those that use ISPF While I admit to using an SPF clone[1] on my PC, I believe that emacs is more common. As to vi, it may well be The Editor From Hell, but it is also the only editor that you can count on finding in an arbitrary *ix system. So keep[2] vi. There are also a number of other editors that some people swear by. [1] Tritus SPF [2] Far from me You don't mention Eclipse which is free and has C/C++ editors for free. SMB or NFS mounts make this a piece of cake. I'm a Slickedit user which supports all mainframe languages, even HLASM. --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Ah, we are taking you from The Century of the Fruitbat into The Century of the Anchovy, are we? If you, or anybody else, understands that without doing a Google/Bing search, I'm impressed by your taste in books! On Sat, Aug 3, 2013 at 9:13 PM, Ze'ev Atlas zatl...@yahoo.com wrote: Why not build the object code for the open source packages using the UNIX file system etc. (and makefile, if you like) I hear you guys and will probably change direction to do it this way. I will go through the documentation and hopefully David will send me some concise explanation that would bring me up to speed. I guess that not all what I did is a waste. For example the COBOL/PLI interfaces, some supporting routines and so on. I also have to see whether I have full access to Unix services. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
I've been considering Slickedit. But it is $299 for a perpetual single user license. A bit steep for me when I'm just a dilettante on Linux. For work, I use ISPF edit and a z/OS shell via ssh. As I've previously confessed, I use vim on Linux. But I'm not into heavy editing. Mainly shell, Perl, and PostgreSQL scripts. On Sun, Aug 4, 2013 at 9:51 AM, David Crayford dcrayf...@gmail.com wrote: You don't mention Eclipse which is free and has C/C++ editors for free. SMB or NFS mounts make this a piece of cake. I'm a Slickedit user which supports all mainframe languages, even HLASM. --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
While I admit to using an SPF clone[1] on my PC, I believe that emacs is more common. As to vi, it may well be The Editor From Hell, but it is also the only editor that you can count on finding in an arbitrary *ix system. So keep[2] vi. My first computer language was Assembler/360. When the PC's came about, I was absolutely capable of learning the Intel Assembler. I made a conscious decision not to do so and relegate low level programming to C. In the same vain, my first text editor was the cryptic and arcane ISPF. When it was time to move to things like Unix, I made a conscious decision not learn yet another cryptic and arcane text editor such as vi or Emacs. On the PC I use Notepad++ and SPFLite (both are for basically for free - you should register with SPFLite and donate to Notepad++. On Linux I use Gedit when it's available. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In CAAJSdjj1OOA=iupx5KGSMtXL9O86=tx739b7s8nf1huhsca...@mail.gmail.com, on 08/04/2013 at 10:12 AM, John McKown john.archie.mck...@gmail.com said: Ah, we are taking you from The Century of the Fruitbat into The Century of the Anchovy, are we? I'm not really up to date on O'Reilly colophons; what book has an anchovy? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In 0918746873146832.wa.zatlas1yahoo@listserv.ua.edu, on 08/04/2013 at 12:45 PM, Ze'ev Atlas zatl...@yahoo.com said: my first text editor was the cryptic and arcane ISPF. I nver found ISPF/PDF EDIT to be cryptic or arcane, and it was certainly better[1] than ATS, CRJEor TOS EDIT. On the PC I use Notepad++ and SPFLite (both are for basically for free If it requires that I use windoze then the price is too high. Also, shareware is not free; you are supposed to register[2] if you decide to use the program. Even if SPFLite were available for OS/2 and Linux, it is missing TSPF features that I rely upon, e.g., the ability to run the same REXX scripts on TSPF as on mainframe SPF. [1] Most of the time [2] The registration fee for all of the shareware that I have used has been quite modest. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Carpe Jugulum by Sir Terry Pratchett. Nothing to do wit O'Reilly, or even computers. But in the books, that was said to indicate progress into a new era. Such as using z/OS UNIX when it is appropriate. Rather than, like my coworkers, rejecting it because it is different from what they are used to. On Aug 4, 2013 12:56 PM, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In CAAJSdjj1OOA=iupx5KGSMtXL9O86=tx739b7s8nf1huhsca...@mail.gmail.com, on 08/04/2013 at 10:12 AM, John McKown john.archie.mck...@gmail.com said: Ah, we are taking you from The Century of the Fruitbat into The Century of the Anchovy, are we? I'm not really up to date on O'Reilly colophons; what book has an anchovy? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Sir Terry's Carpe jugulum is correct Latin for Seize the throat by analogy with Carpe diem, Seize the day. Jugulum is Latin for throat. (The jugular vein in so called because it is in the throat.) It suggests ruthlessness or rashness rather more than it does leading- or bleeding-edgism. As background, Carpe diem . . . is a truncation of Horace's Carpe diem, quam minimum credula postero i.e., seize the day, making minimal assumptions about what comes after it. Making the simplistic one-for-one substitution we thus get Seize the throat, making minimal assumptions about what comes after doing so. I shall leave the implications for UNIX usage to others. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
And I will stop trying to make any jokes. I'm just no good at it because it appears that nobody really gets them in the way that I intended. On Aug 4, 2013 4:46 PM, John Gilmore jwgli...@gmail.com wrote: Sir Terry's Carpe jugulum is correct Latin for Seize the throat by analogy with Carpe diem, Seize the day. Jugulum is Latin for throat. (The jugular vein in so called because it is in the throat.) It suggests ruthlessness or rashness rather more than it does leading- or bleeding-edgism. As background, Carpe diem . . . is a truncation of Horace's Carpe diem, quam minimum credula postero i.e., seize the day, making minimal assumptions about what comes after it. Making the simplistic one-for-one substitution we thus get Seize the throat, making minimal assumptions about what comes after doing so. I shall leave the implications for UNIX usage to others. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 4/08/2013 11:18 PM, John McKown wrote: I've been considering Slickedit. But it is $299 for a perpetual single user license. A bit steep for me when I'm just a dilettante on Linux. For work, I use ISPF edit and a z/OS shell via ssh. As I've previously confessed, I use vim on Linux. But I'm not into heavy editing. Mainly shell, Perl, and PostgreSQL scripts. It's a big ask to fork out $300 on an editor unless your company pays. Mine is actually $400 for a multi-platform license as I run Windows at work and Ubuntu at home. I've also got a Slickedit core plugin for Eclipse for RDz. I'm holding back on the new RDz due to the serious performance issues with Eclipse Juno http://www.jroller.com/andyl/entry/something_is_really_broken_with. How ironic that IBM and vendors are spending millions on Eclipse plug-ins while they leave the core platform to rot. IBM have probably pulled it's developer resources to work on something new like Orion. All roads lead to the cloud these days. On Sun, Aug 4, 2013 at 9:51 AM, David Crayford dcrayf...@gmail.com wrote: You don't mention Eclipse which is free and has C/C++ editors for free. SMB or NFS mounts make this a piece of cake. I'm a Slickedit user which supports all mainframe languages, even HLASM. --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 2/08/2013 6:16 PM, Ze'ev Atlas wrote: Put the following at the top of your source file. *#define* *_POSIX_SOURCE* Wow, it works... thanks Couple of tips for you. If you really want to use PDS libraries for your C source then you should consider using an option file - see the OPTFILE compiler option http://tinyurl.com/m2kfmz5. You can then define FTMs in the option file so you don't need to modify source code, for example DEF(_ALL_SOURCE). In UNIX we do this with a -D option, -D_ALL_SOURCE which is normally specified in the COPTS variable in a makefile. z/OS UNIX supports several different UNIX standards which are enabled by feature test macros (FTM). They are documented here http://tinyurl.com/kojn4xe. IMO, using PDS data sets for open source software packages is going to be a lot of extra work for you. It doesn't make sense to me but I'm sure you have your reasons. It's easy to build PDS load modules from UNIX but if you must you can do so with JCL. //LINKEXEC PGM=IEWBLINK, // PARM='CALL,REUS=RENT,AMODE=31,RMODE=ANY,CASE(MIXED), // DYNAM(DLL),COMPAT=(PM4)' //SYSLMOD DD DISP=SHR,DSN=DOC.LOAD //SYSLIB DD DISP=SHR,DSN=CEE.SCEELIB // DD DISP=SHR,DSN=SYS1.CBC.SCLBSID // DD DISP=SHR,DSN=SYS1.CSSLIB //SYSPRINT DD SYSOUT=A //SYSLIN DD DSN=SYS1.CEE.SCEELIB(CELHS003),DISP=SHR // DD DSN=SYS1.CEE.SCEELIB(CELHSCPP),DISP=SHR // DD DSN=SYS1.CEE.SCEELIB(CELHS001),DISP=SHR // DD DSN=SYS1.CEE.SCEELIB(CELHS001),DISP=SHR // DD DSN=SYS1.CEE.SCEELIB(C128),DISP=SHR // DD DSN=SYS1.CBC.SCLBSID(IOSTREAM),DISP=SHR // DD DSN=SYS1.CBC.SCLBSID(COMPLEX),DISP=SHR // DD * INCLUDE /u/doc/lua-5.1.5/src/lua INCLUDE /u/doc/lua-5.1.5/src/liblua.x ENTRY CEESTART NAMELUA(R) RC=0 /* BTW, I would *seriously* advise you to to build your software in the UNIX file system and not PDS members. The only time I use a PDS is when I'm forced to by my employers and that's because our home grown SCM product is not UNIX aware. You can then enjoy all the benefits and tools available on UNIX, like makefiles. When I first designed the port I made the decision to work in classic z/OS environment so even people who by their employer's preference or just old habit, have to work that way, could use it. I may or may not decide the same for the next open source project. However, I would appreciate if you point me to documentation about make files, etc. in z/OS. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Why not build the object code for the open source packages using the UNIX file system etc. (and makefile, if you like) and only put your own code which makes these things available to your onsite callers in PDSes? I believe that there is no need to put the open source packages into your home grown SCM system. As there will be no normal maintenance to them, this doesn't make sense, IMO. This is what we do ... we then link the open source object code to the gateway functions that make it available to our onsite callers, and only the gateway functions (which is code of our own) it put into our (also home grown) SCM systems. (Or: we call the open source objects dynamically, BTW). The open source code used is of course archived, too, but not in our SCM system. In the worst case: because it's open source, you always can retrieve it again from outside ... Kind regards Bernd Am 03.08.2013 10:46, schrieb David Crayford: IMO, using PDS data sets for open source software packages is going to be a lot of extra work for you. It doesn't make sense to me but I'm sure you have your reasons. It's easy to build PDS load modules from UNIX but if you must you can do so with JCL. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Addendum: some time ago we had some issues when trying to call a SSL package which was compiled using XPLINK on the UNIX filesystem, and the resulting objects resided on PDSEs (type 3 program objects). We tried to call this packages from classical PL/1 load modules, residing on normal PO libraries, being compiled with the NORENT option. But even this worked after some fighting - with some other module in between which served as a gateway between the two worlds, and - of course - dynamic calls, because you cannot do static linkage between non-XPLINK and XPLINK, as I was told. The gateway functions - written in C, 72 columns, PDS format - are stored in the SCM system, the SSL package of course not. Kind regards Bernd Am 03.08.2013 11:59, schrieb Bernd Oppolzer: Why not build the object code for the open source packages using the UNIX file system etc. (and makefile, if you like) and only put your own code which makes these things available to your onsite callers in PDSes? I believe that there is no need to put the open source packages into your home grown SCM system. As there will be no normal maintenance to them, this doesn't make sense, IMO. This is what we do ... we then link the open source object code to the gateway functions that make it available to our onsite callers, and only the gateway functions (which is code of our own) it put into our (also home grown) SCM systems. (Or: we call the open source objects dynamically, BTW). The open source code used is of course archived, too, but not in our SCM system. In the worst case: because it's open source, you always can retrieve it again from outside ... Kind regards Bernd Am 03.08.2013 10:46, schrieb David Crayford: IMO, using PDS data sets for open source software packages is going to be a lot of extra work for you. It doesn't make sense to me but I'm sure you have your reasons. It's easy to build PDS load modules from UNIX but if you must you can do so with JCL. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
The HAVE_*_H FTMs are set by autoconf. I'm guessing that you didn't run the configure script in z/OS unix to build config.h? Definitely not! I did the port strictly in classic z/OS with PDS or PDSE as the source code repository and a simple process I've developed to resolve bind time dependencies. As I've mentioned elsewhere, I had the poor souls who work with that environment in mind and COBOL applications as the target user audience. I may or may not choose to use that technique in my next Open Source project and I may consider redoing the port in z/OS Unix, but for now it is what it is, a classic z/OS port. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Why not build the object code for the open source packages using the UNIX file system etc. (and makefile, if you like) I hear you guys and will probably change direction to do it this way. I will go through the documentation and hopefully David will send me some concise explanation that would bring me up to speed. I guess that not all what I did is a waste. For example the COBOL/PLI interfaces, some supporting routines and so on. I also have to see whether I have full access to Unix services. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
But even this worked after some fighting - with some other module in between which served as a gateway between the two worlds, and - of course - dynamic calls, because you cannot do static linkage between non-XPLINK and XPLINK, as I was told. Would you mind share some samle code to speed my understanding Thanks ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Put the following at the top of your source file. *#define* *_POSIX_SOURCE* Wow, it works... thanks BTW, I would *seriously* advise you to to build your software in the UNIX file system and not PDS members. The only time I use a PDS is when I'm forced to by my employers and that's because our home grown SCM product is not UNIX aware. You can then enjoy all the benefits and tools available on UNIX, like makefiles. When I first designed the port I made the decision to work in classic z/OS environment so even people who by their employer's preference or just old habit, have to work that way, could use it. I may or may not decide the same for the next open source project. However, I would appreciate if you point me to documentation about make files, etc. in z/OS. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 2/08/2013 6:16 PM, Ze'ev Atlas wrote: When I first designed the port I made the decision to work in classic z/OS environment so even people who by their employer's preference or just old habit, have to work that way, could use it. I may or may not decide the same for the next open source project. However, I would appreciate if you point me to documentation about make files, etc. in z/OS. Most people use GNU make which is more portable http://www.gnu.org/software/make/manual/make.html. You can get it from the z/OS UNIX tools and toys site http://www-03.ibm.com/systems/z/os/zos/features/unix/bpxa1ty1.html. You may want to post questions about C, z/OS UNIX etc on the OEMVS newsgroup which is where the experts hang out. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 8/2/2013 6:29 AM, David Crayford wrote: On 2/08/2013 6:16 PM, Ze'ev Atlas wrote: When I first designed the port I made the decision to work in classic z/OS environment so even people who by their employer's preference or just old habit, have to work that way, could use it. I may or may not decide the same for the next open source project. However, I would appreciate if you point me to documentation about make files, etc. in z/OS. z/OS UNIX System Services Command Reference (SA22-7801-14), chapter 2 In Developing Applications for z/OS UNIX (3 days, details at http://www.trainersfriend.com/UNIX_and_Web_courses/u520descr.htm ), we devote almost 20% of the student material to make and makefiles. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html Most people use GNU make which is more portable http://www.gnu.org/software/make/manual/make.html. You can get it from the z/OS UNIX tools and toys site http://www-03.ibm.com/systems/z/os/zos/features/unix/bpxa1ty1.html. You may want to post questions about C, z/OS UNIX etc on the OEMVS newsgroup which is where the experts hang out. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In 51fba643.7040...@gmail.com, on 08/02/2013 at 08:29 PM, David Crayford dcrayf...@gmail.com said: You may want to post questions about C, z/OS UNIX etc on the OEMVS newsgroup which is where the experts hang out. AFAIK there is no such news group; there is an MVS-OE mailing list. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In 6895589374223115.wa.zatlas1yahoo@listserv.ua.edu, on 08/01/2013 at 11:43 PM, Ze'ev Atlas zatl...@yahoo.com said: amp; Does the web interface force you to escape ampersands? It's very hard to read. Did you verify that HAVE_SYS_STAT_H, HAVE_DIRENT_H, HAVE_SYS_TYPES_H and NATIVE_ZOS have the expected values? -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On Fri, 2 Aug 2013 10:11:16 -0400, Shmuel Metz (Seymour J.) wrote: on 08/02/2013 at 08:29 PM, David Crayford said: You may want to post questions about C, z/OS UNIX etc on the OEMVS newsgroup which is where the experts hang out. AFAIK there is no such news group; there is an MVS-OE mailing list. No, that one discusses questions about USS, as I survey the content. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
In 1425773931786337.wa.paulgboulderaim@listserv.ua.edu, on 08/02/2013 at 11:54 AM, Paul Gilmartin paulgboul...@aim.com said: On Fri, 2 Aug 2013 10:11:16 -0400, Shmuel Metz (Seymour J.) wrote: on 08/02/2013 at 08:29 PM, David Crayford said: You may want to post questions about C, z/OS UNIX etc on the OEMVS newsgroup which is where the experts hang out. AFAIK there is no such news group; there is an MVS-OE mailing list. No, that one discusses questions about USS, as I survey the content. What are you trying to say? MVS-OE is an appropriate mailing list for z/OS Unix, which David asked about and there is no OEMVS news group. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Did you verify that HAVE_SYS_STAT_H, HAVE_DIRENT_H, HAVE_SYS_TYPES_H
and NATIVE_ZOS have the expected values?
HAVE_SYS_STAT_H, HAVE_DIRENT_H, HAVE_SYS_TYPES_H are set by the original
package and in z/OS I don't care how they are set.
I set NATIVE_ZOS in my z/OS customized config.h (following and adapting the
instructions on how to port the package as published, plus some of my own
inventions :), so one I do OR operation ('||'), I am in control.
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
The HAVE_*_H FTMs are set by autoconf. I'm guessing that you didn't run the
configure script in z/OS unix to build config.h?
On 03/08/2013, at 4:33 AM, Ze'ev Atlas zatl...@yahoo.com wrote:
Did you verify that HAVE_SYS_STAT_H, HAVE_DIRENT_H, HAVE_SYS_TYPES_H
and NATIVE_ZOS have the expected values?
HAVE_SYS_STAT_H, HAVE_DIRENT_H, HAVE_SYS_TYPES_H are set by the original
package and in z/OS I don't care how they are set.
I set NATIVE_ZOS in my z/OS customized config.h (following and adapting the
instructions on how to port the package as published, plus some of my own
inventions :), so one I do OR operation ('||'), I am in control.
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
On 3/08/2013 4:33 AM, Ze'ev Atlas wrote:
Did you verify that HAVE_SYS_STAT_H, HAVE_DIRENT_H, HAVE_SYS_TYPES_H
and NATIVE_ZOS have the expected values?
HAVE_SYS_STAT_H, HAVE_DIRENT_H, HAVE_SYS_TYPES_H are set by the original
package and in z/OS I don't care how they are set.
I set NATIVE_ZOS in my z/OS customized config.h (following and adapting the
instructions on how to port the package as published, plus some of my own
inventions :), so one I do OR operation ('||'), I am in control.
I just built pcre-8.33 and was impressed by how easy it was build. I ran
./configure --enable-ebcdic make and it built clean straight off the
bat. I ran the test suite and had a quick look at pcregrep which is
significantly more powerful
than POSIX grep. It's my first look a pcre and it's great package.
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C issue - 'struct stat'
Put the following at the top of your source file. *#define* *_POSIX_SOURCE* BTW, I would *seriously* advise you to to build your software in the UNIX file system and not PDS members. The only time I use a PDS is when I'm forced to by my employers and that's because our home grown SCM product is not UNIX aware. You can then enjoy all the benefits and tools available on UNIX, like makefiles. On 2/08/2013 12:43 PM, Ze'ev Atlas wrote: Hi all In working on PCREGREP, the grep utility of the PCRE package I am porting to z/OS, I've encountered an issue that I do not know how to resolve: I figured out that z/OS behaves mostly like UNIX and not like Windows, so I added my macro to this line: #if (defined HAVE_SYS_STAT_H amp; defined HAVE_DIRENT_H amp; defined HAVE_SYS_TYPES_H) || defined NATIVE_ZOS instructing the compiler to choose the next few lines. Notice the #include sys/stat.h: #include sys/types.h #include sys/stat.h #include dirent.h ... struct stat statbuf; ... The manual SA22-7821-13 XL C/C++ Run-Time Library Reference states clearly that sys/stat.h contains a: struct stat definition. I also looked at the library CEE.SCEEH.SYS.H and the said struct is indeed available. Yet I consistently get this error message: ERROR CBC3007 ZATLAS1.DEV.C(QCREGREP):554 struct stat is undefined. And I cannot figure out why. I cannot ask the Unix/Linux crowd since the issue seems to be specific to z/OS compiler. [If you try that at home, there were more issues but they were obvious and I resolved them easily.] Thanks ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
