Re: O/T What 'The Imitation Game' didn't tell you about Turing's greatest triumph - The Washington Post
Here is the tinyurl of Ed's link http://tinyurl.com/l7x9fek PRINCETON, N.J. - Freeman Dyson, 91, the famed physicist, author and oracle of human destiny, is holding forth after tea-time one February afternoon in the common room of the Institute for Advanced Study. Let me tell you the story of how I discovered Turing, which was in 1941, he says. I was just browsing in the library in Cambridge. I hit that 1936 paper. I never heard of this guy Turing, but I saw that paper and immediately I said this is something absolutely great. Computable numbers, that was something that was obviously great. Pause. Then, with a laugh: But it never occurred to me that it would have any practical importance. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Saturday, February 21, 2015 10:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: O/T What 'The Imitation Game' didn't tell you about Turing's greatest triumph - The Washington Post http://www.washingtonpost.com/national/health-science/what-imitation- game-didnt-tell-you-about-alan-turings-greatest-triumph/2015/02/20/ ffd210b6-b606-11e4-9423-f3d0a1ec335c_story.html What 'The Imitation Game' didn't tell you about Turing's greatest triumph -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEASYMxx: How is possible define more than one LPARNAME at same time in SYSDEF?
To answer the question specifically asked, no, you cannot. But Skip's approach can help you accomplish what you want. Careful use of naming conventions of things like system names and LPAR names, and judicious use of symbolics based on those names can help you too. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSMS: Can CDSs and UCAT, be SMS managed or not ??
It occurred to me after my previous post that you were indeed talking about DFSMS itself. I've never been in-house for a migration to SMS, so I don't know the history. I could see a chicken-and-egg problem in putting SMS resources under control of a product that has not yet been installed. ;-) In our case, all SMS related data sets and user catalogs live on non-SMS volumes. I can't see any benefit in making them SMS managed, although you have shown that it's possible. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Toni Cecil Sent: Sunday, February 22, 2015 10:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFSMS: Can CDSs and UCAT, be SMS managed or not ?? Hello, Thx for your replies, I'm talking about DFSMS ACDS,SCDS and COMMDS (i'll refer CDSs hereafter). The reason for this question is that I have all flavours. Systems with UCAT be SMS managed and CDSs not be sms managed. CDSs be SMS managed and UCAT not sms managed. I wonder if there was any not mandatory but very much advisable rule to set up these datasets. In all cases, each of these CDSs is placed in one dedicated dasd volume. Many thx one more, A.Cecilio. On Wed, Feb 18, 2015 at 5:42 PM, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2015-02-18 o 18:27, Toni Cecil pisze: Hello, do you know any consideration to have ACS,SCDS and COMMDS as sms managed or not ?? and how about the catalog where these datasets are placed ?? I'm with z/os V1.13 According to ServerPac Installation Dialog the CDSes have to be cataloged in MCAT, but this is not true. I have never put those CDSes on SMS-managed volume and I think there is good reason for that, like never putting spare door key inside the room. However AFAIR there is no requirement for those datasets to be not SMS-managed. There is no requirement to be SMS-managed as well. HTH -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: O/T What ‘The Imitation Game’ didn’t tell you about Turing’s greatest triumph - The Washington Post
On Sat, 21 Feb 2015 23:34:42 -0600, Ed Gould wrote: http://www.washingtonpost.com/national/health-science/what-imitation- game-didnt-tell-you-about-alan-turings-greatest-triumph/2015/02/20/ ffd210b6-b606-11e4-9423-f3d0a1ec335c_story.html What �The Imitation Game� didn�t tell you about Turing�s greatest triumph Unwrapped, I hope: http://www.washingtonpost.com/national/health-science/what-imitation-game-didnt-tell-you-about-alan-turings-greatest-triumph/2015/02/20/ffd210b6-b606-11e4-9423-f3d0a1ec335c_story.html Ed needs to get a better mail agent. In cases such as this, dumber is probably better than amarter. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSMS: Can CDSs and UCAT, be SMS managed or not ??
Hello, Thx for your replies, I'm talking about DFSMS ACDS,SCDS and COMMDS (i'll refer CDSs hereafter). The reason for this question is that I have all flavours. Systems with UCAT be SMS managed and CDSs not be sms managed. CDSs be SMS managed and UCAT not sms managed. I wonder if there was any not mandatory but very much advisable rule to set up these datasets. In all cases, each of these CDSs is placed in one dedicated dasd volume. Many thx one more, A.Cecilio. On Wed, Feb 18, 2015 at 5:42 PM, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2015-02-18 o 18:27, Toni Cecil pisze: Hello, do you know any consideration to have ACS,SCDS and COMMDS as sms managed or not ?? and how about the catalog where these datasets are placed ?? I'm with z/os V1.13 According to ServerPac Installation Dialog the CDSes have to be cataloged in MCAT, but this is not true. I have never put those CDSes on SMS-managed volume and I think there is good reason for that, like never putting spare door key inside the room. However AFAIR there is no requirement for those datasets to be not SMS-managed. There is no requirement to be SMS-managed as well. HTH -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.840.228 złotych. -- 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: IEASYMxx: How is possible define more than one LPARNAME at same time in SYSDEF?
On Sat, Feb 21, 2015 at 6:41 PM, J O Skip Robinson jo.skip.robin...@sce.com wrote: SYMDEF(CTCPID#1='i-xxx,i-yyy') /* SET INPUT ADDRESS LIST */ SYMDEF(CTCPOD#1='o-xxx,o-yyy') /* SET OUTPUT ADDRESS LIST */ For clarification, does 'xxx' represent the address on z196-1, and 'yyy' the address on z196-2? Or are both addresses defined to the same HWNAME? I glanced at both MVS Init Tuning Reference and Setting up a Sysplex, but didn't find a good description of the behavior (or benefits?) of specifying multiple devices. I interpreted the OP's question to relate more on how to handle the TEST systems when PROD systems move around, and was going to suggest using SETXCF MODIFY command on the TEST LPARs to specify new Inbound/Outbound addresses for the new PROD connections. Symbolics could still be used in that case, defining normal operations addresses, and FDR addresses when PROD is on alternate hardware. If 'yyy' automagically takes over when 'xxx' is not available, then a lot less manual effort (in the form of console commands) would be required. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: O/T What ŒThe Imitation Game¹ didn¹t tell you about Turing¹s greatest tri...
Well what if you just use the higher nodes and navigate? http://www.washingtonpost.com/national/health-science/ Does OK in IE11. Heard Grace Hopper(Adm-USN) speak several times and met her at DOD courses at Navy Yard. She mentioned Turing several times but don't know environment. One that Turing was famous for programing around failing portions of their processor. The other was his early implementation of Virtual - DUZ. Used to be a soap powder commercial 'Duz does everything'. In a message dated 2/22/2015 2:29:08 P.M. Central Standard Time, 000433f07816-dmarc-requ...@listserv.ua.edu writes: I avoid those. Whatever their business models, their revenues depend on tracking the person who supplies them and those who click on them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: O/T What The Imitation Game¹ didn¹t tell you about Turing¹s greatest triumph - The Washington Post
At 08:56 -0600 on 02/22/2015, Paul Gilmartin wrote about Re: O/T What The Imitation Game¹ didn¹t tell you abo: On Sat, 21 Feb 2015 23:34:42 -0600, Ed Gould wrote: http://www.washingtonpost.com/national/health-science/what-imitation- game-didnt-tell-you-about-alan-turings-greatest-triumph/2015/02/20/ ffd210b6-b606-11e4-9423-f3d0a1ec335c_story.html What ?The Imitation Game? didn?t tell you about Turing?s greatest triumph Unwrapped, I hope: http://www.washingtonpost.com/national/health-science/what-imitation-game-didnt-tell-you-about-alan-turings-greatest-triumph/2015/02/20/ffd210b6-b606-11e4-9423-f3d0a1ec335c_story.html Ed needs to get a better mail agent. In cases such as this, dumber is probably better than amarter. Or just use a URL Shortener. -- 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: O/T What ŒThe Imitation Game¹ didn¹t tell you about Turing¹s greatest triumph - The Washington Post
On Sun, 22 Feb 2015 15:05:29 -0500, Robert A. Rosenberg wrote: Unwrapped, I hope: http://www.washingtonpost.com/national/health-science/what-imitation-game-didnt-tell-you-about-alan-turings-greatest-triumph/2015/02/20/ffd210b6-b606-11e4-9423-f3d0a1ec335c_story.html Ed needs to get a better mail agent. In cases such as this, dumber is probably better than amarter. Or just use a URL Shortener. I avoid those. Whatever their business models, their revenues depend on tracking the person who supplies them and those who click on them. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: High i/o rate and CPU usage by catalog after converting a set of files to extended and placing them on model 54's
Sheldon, His logic is not clear to me .can you detail a tad more .. Regards, Scott On Sunday, February 22, 2015, Sheldon Davis sda...@isracard.co.il wrote: I have managed to recreate the problem. I will open a PMR and I will check with the developer why he is doing what he is. A cobol program reads input and then opens file (disp=mod) writes record and then closes file (50k times) The following are the results of my tests: Open file write 50k records close file - file size 30 tracks less than a second CPU 50k times on a non extended file open write close - file size 600 tracks 3 minutes CPU 50k times on an extended file open write close- file size 23000 tracks 8 minutes CPU (catalog address space doing high i/o on vvds of disk being written to -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU javascript:;] On Behalf Of Sheldon Davis Sent: Wednesday, February 18, 2015 11:45 PM To: IBM-MAIN@LISTSERV.UA.EDU javascript:; Subject: High i/o rate and CPU usage by catalog after converting a set of files to extended and placing them on model 54's Hi I am out of ideas. We converted a set of sequential files to be extended and changed the ACS routine to put the files on model 54's The following is what happened: 1. Jobs that allocated the files took more CPU and ran much longer. 2. The catalog address space used about four times more CPU than usual and did a huge amount of I/O on the disks that the batch job used to allocate and update the files. Thanks for any input -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; 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: A possible bug in the IBM Runtimne C library
To give you an example on the different alignment strategy of (for example)
PL/1 and C:
let's assume a structure
typedef struct
{
short a;
int b;
short c;
int d;
}
example;
in PL/1;
DCL 1 EXAMPLE,
3 A BIN FIXED (15),
3 B BIN FIXED (31),
3 C BIN FIXED (15),
3 D BIN FIXED (31);
These two definitions will not match, because:
in C there are two padding bytes after a and after c; the whole structure
starts at an address multiple of 4, because there are ints inside the
structure.
In PL/1, B has to be on a 4 byte boundary. To save padding bytes, the
beginning
of the structure will be in the middle of a full word, that is: on an
offset that has
remainder 2 when divided by 4. So the offsets of the structure
components are
different; when the structures are overlaid, the fields don't match.
To get around this, we put dummy double precisions fields (with the
highest possible
alignment needs) in the front of every such structure. Then the offsets
and paddings
of the remaining fields will be in sync.
(BTW: if there are multiple instances of the PL/1 structure, for example
in an array,
the PL/1 technique does not save anything, because the padding fields
now appear
at the end of the structure ... before the next element begins).
Kind regards
Bernd
Am 23.02.2015 um 08:37 schrieb Bernd Oppolzer:
Hello Ze'ev,
unless the structure is defined with the nonstandard extension Packed
(or _Packed, I don't recall it exactly), all ints or longs will be
aligned on
a 4 byte boundary, that is, in a sequence of int, short, int, short,
you will
get two padding bytes after every short field (which is in fact 2
bytes long).
Same goes for PL/1 with a sequence of BIN FIXED(31) and BIN FIXED(15)
fields. The rules for alignment with PL/1 are more complicated than
with C.
Structures in C always start with the highest needed alignment
required inside
the structure, while in PL/1 there is some work done to start the
structure at
an offset which minimizes the padding bytes in the middle of the
structure
(short story, the long explanation in the PL/1 books needs many pages).
You can synchronize alignment between PL/1 and C, if you put a dummy
double precision field (which has alignment requirement of 8) in front
of the structure.
The the two languages do the same. A similar technique should work for
COBOL, too.
Kind regards
Bernd
Am 23.02.2015 um 03:44 schrieb Ze'ev Atlas:
__off_t is clearly defined earlier as a 32 bit entity but mbstate_t
is defined as short which I assumed is a 16 bit entity. Either short
is NOT 16 bits but 32 bit entity as well, or the C compiler leaves 2
bytes of zeroes in order to keep the correct integral boundary.
However, in REAL LIFE there are 32 bits between rm_so and rm_eo. I
did not bother to investigate too much ...
--
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: O/T What The Imitation Game¹ didn¹t tell you about Turing¹s greatest triumph - The Washington Post
I don't know what the problem is on my end as I am able to click on the url and it took me to the desired location, so I suspect the issue is either with the list serv or your mail client. Ed On Feb 22, 2015, at 2:05 PM, Robert A. Rosenberg wrote: At 08:56 -0600 on 02/22/2015, Paul Gilmartin wrote about Re: O/T What ŒThe Imitation Game¹ didn¹t tell you abo: On Sat, 21 Feb 2015 23:34:42 -0600, Ed Gould wrote: http://www.washingtonpost.com/national/health-science/what- imitation- game-didnt-tell-you-about-alan-turings-greatest-triumph/2015/02/20/ ffd210b6-b606-11e4-9423-f3d0a1ec335c_story.html What ?The Imitation Game? didn?t tell you about Turing?s greatest triumph Unwrapped, I hope: http://www.washingtonpost.com/national/health-science/what- imitation-game-didnt-tell-you-about-alan-turings-greatest-triumph/ 2015/02/20/ffd210b6-b606-11e4-9423-f3d0a1ec335c_story.html Ed needs to get a better mail agent. In cases such as this, dumber is probably better than amarter. Or just use a URL Shortener. -- 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
Re: A possible bug in the IBM Runtimne C library
Hello Ze'ev, unless the structure is defined with the nonstandard extension Packed (or _Packed, I don't recall it exactly), all ints or longs will be aligned on a 4 byte boundary, that is, in a sequence of int, short, int, short, you will get two padding bytes after every short field (which is in fact 2 bytes long). Same goes for PL/1 with a sequence of BIN FIXED(31) and BIN FIXED(15) fields. The rules for alignment with PL/1 are more complicated than with C. Structures in C always start with the highest needed alignment required inside the structure, while in PL/1 there is some work done to start the structure at an offset which minimizes the padding bytes in the middle of the structure (short story, the long explanation in the PL/1 books needs many pages). You can synchronize alignment between PL/1 and C, if you put a dummy double precision field (which has alignment requirement of 8) in front of the structure. The the two languages do the same. A similar technique should work for COBOL, too. Kind regards Bernd Am 23.02.2015 um 03:44 schrieb Ze'ev Atlas: __off_t is clearly defined earlier as a 32 bit entity but mbstate_t is defined as short which I assumed is a 16 bit entity. Either short is NOT 16 bits but 32 bit entity as well, or the C compiler leaves 2 bytes of zeroes in order to keep the correct integral boundary. However, in REAL LIFE there are 32 bits between rm_so and rm_eo. I did not bother to investigate too much ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: High i/o rate and CPU usage by catalog after converting a set of files to extended and placing them on model 54's
I had this situation once when I was sharing a catalog between two LPARs. The catalogue were large and were being updated by both systems. It turn out that when a update from system A is done to the catalog, buffers are invalidated on system B. When system B need to inquire on a dataset, all the required buffers need to be re-read. If system A and B keep invalidating each other's buffers, high CPU and I/O are required to protect the integrity of the catalog. Just a thought from my experience. Chip On Feb 22, 2015, at 16:20, Scott Ford idfzos...@gmail.com wrote: Sheldon, His logic is not clear to me .can you detail a tad more .. Regards, Scott On Sunday, February 22, 2015, Sheldon Davis sda...@isracard.co.il wrote: I have managed to recreate the problem. I will open a PMR and I will check with the developer why he is doing what he is. A cobol program reads input and then opens file (disp=mod) writes record and then closes file (50k times) The following are the results of my tests: Open file write 50k records close file - file size 30 tracks less than a second CPU 50k times on a non extended file open write close - file size 600 tracks 3 minutes CPU 50k times on an extended file open write close- file size 23000 tracks 8 minutes CPU (catalog address space doing high i/o on vvds of disk being written to -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU javascript:;] On Behalf Of Sheldon Davis Sent: Wednesday, February 18, 2015 11:45 PM To: IBM-MAIN@LISTSERV.UA.EDU javascript:; Subject: High i/o rate and CPU usage by catalog after converting a set of files to extended and placing them on model 54's Hi I am out of ideas. We converted a set of sequential files to be extended and changed the ACS routine to put the files on model 54's The following is what happened: 1. Jobs that allocated the files took more CPU and ran much longer. 2. The catalog address space used about four times more CPU than usual and did a huge amount of I/O on the disks that the batch job used to allocate and update the files. Thanks for any input -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; 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: A possible bug in the IBM Runtimne C library
I want to publicly thank Retired Mainframer for leading me to the correct
direction. The problem was that the EBCDIC oriented regmatch_t structure is
defined like this:
typedef struct { /* substring locations - from regexec() */
__off_t rm_so; /* offset of substring */
mbstate_t rm_ss; /* Shift state at start of substring*/
__off_t rm_eo; /* offset of first char after substring */
mbstate_t rm_es; /* Shift state at end of substring */
} regmatch_t;
__off_t is clearly defined earlier as a 32 bit entity but mbstate_t is defined
as short which I assumed is a 16 bit entity. Either short is NOT 16 bits but
32 bit entity as well, or the C compiler leaves 2 bytes of zeroes in order to
keep the correct integral boundary. However, in REAL LIFE there are 32 bits
between rm_so and rm_eo. I did not bother to investigate too much but
translated the structure as:
10 :PREFIX:-regmatch-t.
15 :PREFIX:-rm-so PIC S9(9) COMP-5.
* offset of substring */
15 :PREFIX:-rm-ss PIC s9(4) COMP-5.
* Shift state at start of substring*/
15 FILLER PIC XX.
* The filler was added since despite the fact that the C
* calls for short rm-ss and rm-es (i.e. S9(4) COMP-5) allocates
* 4 bytes, either because short is not short after all or
* because of integral boundary.
15 :PREFIX:-rm-eo PIC S9(9) COMP-5.
* offset of first char after substring */
15 :PREFIX:-rm-es PIC S9(4) COMP-5.
* Shift state at end of substring */
15 FILLER PIC XX.
compensating for the additional two bytes after each pair. After all, we
always use EBCDIC!
I've published the results of my work as FILE928 in the CBTTAPE with a demo
program and explanation how to extract a captured substring (in addition to the
regular match/no-match capability.
I will also publish it in my own website later.
The reason for this work is that the only serious argument I've ever heard for
not using my port of the PCRE library was that management would never allow
use of Open Source. One can freely take my copybooks that only describe
structures and use them with the bona-fide IBM supplied functions. Please feel
free to copy the definition only and avoid the open Source mambo Jumbo if you
do not intend to distribute your poor COBOL program!
ZA
ZA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
