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: IN
In
<1324425089-1376535875-cardhu_decombobulator_blackberry.rim.net-1454793260-@b4.c1.bise6.blackberry>,
on 08/15/2013
at 03:04 AM, Ted MacNEIL 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
In <520c4685.2070...@gmail.com>, on 08/15/2013
at 11:09 AM, David Crayford 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
>servic
In <6448819105643178.wa.zatlas1yahoo@listserv.ua.edu>, on
08/14/2013
at 09:30 PM, "Ze'ev Atlas" 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 w
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 ther
List
Date: Thu, 15 Aug 2013 00:16:14
To:
Reply-To: IBM Mainframe Discussion List
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
>>poi
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!
>Applicatio
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 t
>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
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 e
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
>nam
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
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 charact
>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
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
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 para
>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 acc
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.
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
>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
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
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
On Sat, 10 Aug 2013 07:42:50 +0800, David Crayford wrote:
>That's the one CASE(MIXED), UPPER is the default.
>
And the reporting is perverse. If with the default in effect, you do:
INCLUDE SYS00011(wombat.foobar)
Binder does
stat( "WOMBAT.FOOBAR" )
... gets ENOENT; then reports (som
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 m
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
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 COB
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 wrote:
> Normally, if you compile
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
That's the one CASE(MIXED), UPPER is the default.
On 10/08/2013, at 7:35 AM, Paul Gilmartin 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
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 thin
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 wrote:
> you wrote:
>
> shortening the functions' names to 8, upper case characters,
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 name
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. A
In <5499902479450252.wa.paulgboulderaim@listserv.ua.edu>, on
08/08/2013
at 11:07 AM, Paul Gilmartin 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;
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 <00d501ce937a$2c525710$84f70530$@mcn.org>, on 08/07/2013
at 10:26 AM, Charles Mills 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.
In <2883356613158771.wa.paulgboulderaim@listserv.ua.edu>, on
08/07/2013
at 08:34 AM, Paul Gilmartin 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.
A
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 contro
: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
&
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 program
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 wrote:
> O
On 07/08/2013, at 9:34 PM, Paul Gilmartin 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 pointe
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 di
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
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
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 m
>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 applicatio
In <6327543196613690.wa.paulgboulderaim@listserv.ua.edu>, on
08/05/2013
at 11:16 AM, Paul Gilmartin 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 example, because the
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:
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.
In <51ff03c9.8010...@gmail.com>, on 08/05/2013
at 09:45 AM, David Crayford 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
>assume
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"
progra
ly 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'
>
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
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" wrote:
> Sir Terry's Carpe jugulum is correct Latin for "Seize the throat" by
> analogy with Carpe diem, "Seize the d
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
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 no
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
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 8/4/2013 at 12:24 PM, Paul Gilmartin 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 to the ma
In <0918746873146832.wa.zatlas1yahoo@listserv.ua.edu>, on
08/04/2013
at 12:45 PM, "Ze'ev Atlas" 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 Not
In
,
on 08/04/2013
at 10:12 AM, John McKown 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/2
>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 P
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 err
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
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 wrote:
> >Why not build the object c
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 wrote:
> On 4/08/2013 10:38 PM, Shmuel Metz (Seymour J.) wrote:
>
>> In
>> <1229979691582383.WA.**zatlas1yahoo@listserv.ua.**edu<1229979691582383.
In <51fe6a71.2060...@gmail.com>, on 08/04/2013
at 10:51 PM, David Crayford 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
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" 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 bel
In <1229979691582383.wa.zatlas1yahoo@listserv.ua.edu>, on
08/04/2013
at 12:59 AM, "Ze'ev Atlas" 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
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 && gmake
...
Simple as that. Took less than 10 minutes end-to-end.
Surprising. I never got configure to ru
On Sun, 4 Aug 2013 16:30:21 +0800, David Crayford wrote:
>...
>4. build the software
>
> cd pcre-8.33
> ./configure --enable-ascii && 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/O
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 && 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 gre
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 alm
>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
>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
>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'
>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
depen
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
librar
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
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
co
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 i
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 wrote:
>> Did you verify that HAVE_SYS_STAT_H, HAVE_DIRENT_H, HAVE_SYS_TYPES_H
>> and NATIVE_ZOS have the expected values?
>
> HA
>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
In <1425773931786337.wa.paulgboulderaim@listserv.ua.edu>, on
08/02/2013
at 11:54 AM, Paul Gilmartin 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
@LISTSERV.UA.EDU
Subject: 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 th
On Fri, 2 Aug 2013 20:29:55 +0800, 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
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 ma
In <6895589374223115.wa.zatlas1yahoo@listserv.ua.edu>, on
08/01/2013
at 11:43 PM, "Ze'ev Atlas" said:
>&&
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 v
In <51fba643.7040...@gmail.com>, 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.
--
Shmuel (Seymour
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 d
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 p
>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
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 produc
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 && defined
95 matches
Mail list logo
