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
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
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.
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:
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
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
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,
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
On Wed, 14 Aug 2013 15:57:31 -0400, John Gilmore wrote:
It is very late in the day to introduce a new PDS as opposed to PDSE
library of this sort.
It can be environmentally dictated. In our lab we have more systems
at more releases (some unsupported, but you know how customers
are) than
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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:
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
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,
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
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
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
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
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
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.
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
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.
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
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
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
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.
: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
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
[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
.
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
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
In 51ff03c9.8010...@gmail.com, on 08/05/2013
at 09:45 AM, David Crayford dcrayf...@gmail.com said:
I'm not sure but whoever it was knows what they are doing. It's a
very good implementation. It even handles the newline fiasco.
The EBCDIC character that corresponds to an ASCII LF is
On Mon, 5 Aug 2013 10:34:56 -0400, Shmuel Metz (Seymour J.) wrote:
The problem is Unix, not EBCDIC. The ASCII LF is *not* a new line
function, but half of a new line function. The DOS CRLF convention
reflects ASCII. '15'x is a correct translation of the Unix new line
but not of the ASCII LF. '25'
On Mon, 5 Aug 2013 11:16:25 -0500, Paul Gilmartin wrote:
Linux iconv
ITYM GNU iconv.
--
Tom Marchant
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message:
In 6327543196613690.wa.paulgboulderaim@listserv.ua.edu, on
08/05/2013
at 11:16 AM, Paul Gilmartin paulgboul...@aim.com said:
All of which is comparable to, and irrelevant as, quibbling about
whether, in EBCDIC, x'F1' is a real representation of the CCW to
skip to top-of-form.
Good
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
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
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
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
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
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
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
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,
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
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
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
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
On Sun, 4 Aug 2013 10:38:12 -0400, Shmuel Metz (Seymour J.) wrote:
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
Vi is a study in fencepost errors.
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
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;
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
On 8/4/2013 at 12:24 PM, Paul Gilmartin paulgboul...@aim.com wrote:
I was lately shocked and dismayed to discover on a certain Linux
system that visudo dropped me into not vi, but nano. I
can't even figure out where that's configured; perhaps it's
compiled in. How could they!?
According
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.
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
On Sun, 4 Aug 2013 12:25:57 -0600, Mark Post wrote:
According to the man page:
The following environment variables may be consulted depending on the value of
the editor and env_editor sudoers settings:
VISUAL Invoked by visudo as the editor to use
EDITOR Used by visudo if VISUAL is not set
On 5/08/2013 6:47 AM, Paul Gilmartin wrote:
On Sun, 4 Aug 2013 12:25:57 -0600, Mark Post wrote:
According to the man page:
The following environment variables may be consulted depending on the value of
the editor and env_editor sudoers settings:
VISUAL Invoked by visudo as the editor to use
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,
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
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
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
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
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
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
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
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
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
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
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.
--
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
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
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
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
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
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
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;
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
90 matches
Mail list logo
