Re: JCL PARM issue
It seems to work with 7 quotes in the beginning, etc. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL PARM issue
Could you please apply that to my original parameter as the program should see it: [Take the parameter you want to pass, double the apostrophes, put apostrophes around it, double the apostrophes and put apostrophes around that] Do you mean: 1. 'abc¬*' PCRE2.TESTLIB(GRPIN) 2. ''abc¬*'' PCRE2.TESTLIB(GRPIN) 3. '''abc¬*'' PCRE2.TESTLIB(GRPIN)' 4. ''abc¬* PCRE2.TESTLIB(GRPIN)'' 5. '''abc¬* PCRE2.TESTLIB(GRPIN)''' I will try that ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JCL PARM issue
What am I doing wrongI have doubled every single quote within the string, that should be:'''abc¬*' PCRE2.TESTLIB(GRPIN)'' ||| | +-+ |||++|+--+where the external quotes are the enclosing quotes.So the actual PARM field looked like: // EXEC RUNGREP,TEST='-- Test 15 -',// PARM1='abc¬*'' PCRE2.TESTLIB(GRPIN)''' ++TEST8 EXEC PGM=PCR2GREP, ++ PARM= IEFC653I SUBSTITUTION JCL - PGM=PCR2GREP,PARM=''abc¬*' Why does JCL drop the rest of PARM1?Thank you all Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reading a dump
Thank you all I am looking at your suggestions, but the issue was not really the dump but how I compile and bind the thing. I am away from our beloved z/OS most of the time, but with your help I figure it out. Ze'ev -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Reading a dump
I admit that I am rusty and did not look at any dump for decades, and when I did I was coding either Assembler or COBOL and I knew how to decipher the thing.I am porting a C library libxc to classic z/OS and it compiles cleanly (most of it, at least). As is implied by the description, most users of that thing are running it on Linux or Windows. Maybe a few on Unix machines. I tried to run its modules on my z/OS machine (genuine IBM, z/OS 2.4), and I get S0C4, with nice SYSUDUMP! I have no idea how to begin to look and I am afraid that I compiled it with wrong options. Is there any C maven in the audience that could please try to guide me where to begin looking. I tried to avoid compiling it as dll (that much I sort of knew) but I am not sure any more. Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PCRE2 10.35 with LE and Rexx API is available
Hi AllPCRE2 10.35 with LE and Rexx API is available in CBTTAPE.org, file939 Please try the Rexx API which really is simple and smooth and bring Regular Expressions to TSO-Rexx Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PCRE2 for z/OS version 10.34a (interim release)
I've just published version 10.34a of PCRE2 (Perl Compatible Regular Expressions) for z/OS. This is an interim release, while there is no change in the core library, we've introduced the 'substitute' functionality into the Rexx API. The distribution is available on file939 of the CBTTAPE.org (currently, in the 'UPDATE' page) http://cbttape.org/ftp/updates/CBT939.zip) and eventually will move to the main page ( http://cbttape.org/ftp/cbt/CBT939.zip) in few months The distribution includes a working simple API for Rexx and COBOL demo programs that demonstrates the usage in COBOL and other LE languages. The Rexx API includes an Assembler program that could also be used to demonstrate the usage from Assembler. Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PCRE2 (Perl Compatible Regular Expressions) for z/OS 10.34 is available
I've just published version 10.34 of PCRE2 (Perl Compatible Regular Expressions) for z/OS. The distribution is available on file939 of the CBTTAPE.org (currently, in the 'UPDATE' page) http://cbttape.org/ftp/updates/CBT939.zip) and eventually will move to the main page ( http://cbttape.org/ftp/cbt/CBT939.zip) in few months The distribution includes a working simple API for Rexx and a COBOL demo program that demonstrates the usage in COBOL. The Rexx API includes an Assembler program that could be used to demonstrate the usage from Assembler. There are no significant changes in the z/OS side. Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PCRE2 (Perl Compatible Regular Expressions) for z/OS 10.33 is available
I've just published version 10.33 of PCRE2 (Perl Compatible Regular Expressions) for z/OS.The distribution is available on file939 of the CBTTAPE.org (currently, in the 'UPDATE' page) http://cbttape.org/ftp/updates/CBT939.zip and eventually will move to the main page (http://cbttape.org/ftp/cbt/CBT939.zip) in few months The distribution includes a working simple API for Rexx and a COBOL demo program that demonstrates the usage in COBOL. The Rexx API includes an Assembler program that could be used to demonstrate the usage from Assembler. Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PCRE2 10.32 for z/OS is now available.
PCRE2 10.32 for z/OS is now available. This is a bugfix release. Note that there is a bugfix also in the Assembler part (i.e. the C14.MACLIB and PCRE2.ASM libraries) pertaining to the REXX API.It is available in the usual place, file 939 on CBTTAPE.ORG Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C macro processor - supply exteranl values - emulating CMake
Gil, I do NOT use make! I use JCL for this particular port, as it is designed to be used without Unix Services. In my day job, I use Solaris, Windows and perhaps Linux and I am well aware about these tools (make, gcc, etc.) although usually I do not use them because I do not use compiled languages that much any more. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C macro processor - supply exteranl values - emulating CMake
Thank you Gil You have confirmed what I suspected since I've seen the code. The developer has introduced a non-standard code that is compatible only with GNU make. I have already complained about the issue as introduction of non-standard code would definitely hamper any port to a non 'make' environment. What I will probably do is, in my port scripts (I have a whole system to automate the port, resolve dependencies, etc.), I will add some logic to replace these values with known external values (from a config file), or spit an error message when a new, yet unseed such value is introduced. Basically, mimic the 'make' action in that regard. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C macro processor - supply exteranl values - emulating CMake
I did DEF(@macroname@=1) and it seems not to work. i.e. #define MACRONAME @macroname@ #if MACRONAME ... #else ... #endif did not yield the desired results -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C macro processor - supply exteranl values - emulating CMake
This seems to be a good idea I will try to do: DEF(@xxx@=1) and see if it works As for Gil's question, yeah it is an open source (PCRE2) that is usually dealt with by gcc and make. If the idea above worls themn I am done ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C macro processor - supply exteranl values - emulating CMake
Unfortunately, this is NOT the case I do have several cases were a macro is not defined in the source code but supplied, macro and value by the mechanism: DEF(MACRONAME=somevalue) Here I encountered something else (I assume it is a CMake and gcc construct). The macro is not defined externally, but in the source code: #DEFINE MACRONAME @macroname@ and the make process would supply the value to substitute the @macroname@. My question is whether IBM C run via JCL has a mechanism to supply the value only. I believe that this is a non-standard feature that the GNU guys are pushing on us. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
C macro processor - supply exteranl values - emulating CMake
Hi allI am using IBM C compiler via good ol' JCL. I already know how to supply external macro definitions by supplying://OPTFILE DD DSN=MY.LIB(OPTFILE),...and an OPTFILE member that contains lines like:DEF(HAVE_STDINT_H)or evenDEF(HAVE_STDINT_H=1) I have a new challenge, something like:#define HAVE_STDINT_H @HAVE_STDINT_H@which means that I should not define the macro externally, but get only the value from CMake… I do not have CMake and I do not use it since I run with good ol' JCL. Is there a way to supply the value only? Thank you Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Announcing PCRE2 10.31 for z/OS
I have just released PCRE2 10.31 for z/OS. It is in the usual place - file939 in CBTTAPE.ORG. Currently it is in the updates page. Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PCRE2 for z/OS 10.30 plus REXX API
Announcing PCRE2 for z/OS 10.30 with REXX API I've just sent to the CBT (file 939) a new interim release of PCRE2 for z/OS 10.30 . It is the same as the latest PCRE for z/OS 10.30, but with the addition of 1. comprehensive and workable REXX API, contributed by John Gateley2. Support (almost behind the scene) for multi versions of EBCDIC. 3. This support is available to all PCRE2 users, and is also incorporated into the Rexx API Please see the documents:release_notes.txtEBCDIC_Horror.txtREXXAPI.txt in the distribution file The pcre2doc.txt was not changes but is due to major revision by the next release Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: C/C++ Runtime Library
Thank you everybody for the answers.The ZS, ARCH and TUNE numbers will be taken into account Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
C/C++ Runtime Library
I hope that I word my question correctlyIs the C/C++ Runtime Library installed by default on z/OS or is it a product that needs to be licensed separately?In other words, if I distribute a software product, written in C, in binary form (load modules) and that product rely on the runtime library, what is the likelihood that the client's installations out there would not be able to run the product because the runtime library is not present? Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Regular Expressions with Rexx
John Gateley and I will be publishing a full Rexx API to Perl Compatible Regular Expression package in z/OS, probably next week. This release will be complete if somewhat primitive, comparing to the experimental 1st release. I have noticed that there is not a lot of interest in that subject, which I understand, knowing the Rexx culture. However many of you do Java, ooRexx and are exposed to regular expressions even in Rexx context. I would like to get feedback about the whole subject and about the API (I will publish its availability on the same lists) Ze'ev Atlas | | Virus-free. www.avast.com | -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PCRE2 10.30 released on CBTTAPE (file 939)
A new version of the PCRE2 regex engine for z/OS was released and would be posted on CBTTAPE (file 939) soon. 1. The main interpreter, pcre2_match(), has been refactored into a new version that does not use recursive function calls (and therefore the stack) for remembering backtracking positions. This makes --disable-stack-for-recursion a NOOP. The new implementation allows backtracking into recursive group calls in patterns, making it more compatible with Perl, and also fixes some other hard-to-do issues such as #1887 in Bugzilla. The code is also cleaner because the old code had a number of fudges to try to reduce stack usage. It seems to run no slower than the old code. We are looking for volunteers for two potential improvements:1. A PL/I expert to create native PL/I include modules for full PL/I support (I have some idea how to code in PL/I, but an expert would do a better job.)2. A CEEPIPI expert to help us persist the library for the Rexx API to allow less costly Rexx support (John Gateley wrote a very good and working basic Rexx API, but without persisting the library in the LE environment. every call has to start the expensive compile from scratch. I admit that I tried to read the CEEPIPI documentation several times, just to conclude that I have no idea what does IBM talk about.) Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I am getting IEW2606S in HEWL despite the fact that the target library IS PDSE
AppologyMy bug is obvious, my syslmod is a temp library Ze'ev Atlas IEW2606S 4B39 MODULE INCORPORATES VERSION 3 PROGRAM OBJECT FEATURES AND CANNOT BE SAVED IN LOAD MODULE FORMAT. XXSYSLMOD DD DSNAME= IEFC653I SUBSTITUTION JCL - DSNAME=&(GO),DISP=(MOD,PASS),SPACE=( -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
I am getting IEW2606S in HEWL despite the fact that the target library IS PDSE
=* //OPTFILE DD DSN=(OPTFILE),DISP=SHR IEFC653I SUBSTITUTION JCL - DSN=ZATLAS1.PCRE2.JCLLIB(OPTFILE),DISP=SHXXLKED EXEC PGM=HEWL,COND=(4,LT,COMPILE), XX REGION=,PARM='' IEFC653I SUBSTITUTION JCL - PGM=HEWL,COND=(4,LT,COMPILE),REGION=1024K//LKED.SYSLIB DD X/SYSLIB DD DSNAME=,DISP=SHR IEFC653I SUBSTITUTION JCL - DSNAME=CEE.SCEELKED,DISP=SHR // DD DSN=,DISP=SHR IEFC653I SUBSTITUTION JCL - DSN=ZATLAS1.PCRE2.LOADLIB,DISP=SHR XXSYSPRINT DD SYSOUT=* XXSYSLIN DD DSNAME=*.COMPILE.SYSLIN,DISP=(OLD,DELETE) XX DD DDNAME=SYSIN XXSYSLMOD DD DSNAME= IEFC653I SUBSTITUTION JCL - DSNAME=&(GO),DISP=(MOD,PASS),SPACE=(XXSYSUT1 DD UNIT=,SPACE= IEFC653I SUBSTITUTION JCL - UNIT=SYSALLDA,SPACE=(32000,(30,30)) //SYSIN DD DSN=(),DISP=SHR IEFC653I SUBSTITUTION JCL - DSN=ZATLAS1.PCRE2.CNTLLIB(CONVERT2),DISP=X/SYSIN DD DUMMY with a bunch of include statements: BATCH EMULATOR JOB(ZATLAS1C) STEP(STEP16 ) PGM= HEWL PROCEDURE(LKED )IEW2278I B352 INVOCATION PARAMETERS - AMODE=31,MAP IEW2322I 1220 1 INCLUDE SYSLIB(STRINGU2) IEW2322I 1220 2 INCLUDE SYSLIB(CONTEXT2) IEW2606S 4B39 MODULE INCORPORATES VERSION 3 PROGRAM OBJECT FEATURES AND CANNOT Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PCRE2 10.23 released on CBTTAPE (file 939)
A new version of the PCRE2 regex engine for z/OS was released and would be posted on CBTTAPE (file 939) soon. New in this release is Rexx API. It is implemented as a Rexx function, written in Assembler by John Gateley. It accepts basic regular expressions and some minimal options and returns a Rexx stem. I would like to thank John for his help in that Rexx API. Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: interfacing between PL/I and C
Thank you all Sent from Yahoo Mail on Android On Tue, Feb 21, 2017 at 9:51 PM, Ze'ev Atlas<zatl...@yahoo.com> wrote: Do i need the pragma in the C program if iuse the enterprize PLI. If this is not needed anymore then I am good. The types are non-issue, only the linkageThank youZA Sent from Yahoo Mail on Android On Tue, Feb 21, 2017 at 1:15 PM, Ze'ev Atlas<zatl...@yahoo.com> wrote: Hi all,I hope someone can guide me. I have a C library that I want to call from PL/I. I actually have to create an intrface module for some reasons. If I code it in C using #pragma linkage (..., PLI) I have no prlblem communicating between the C and the PL/I, but then the C cannot communicate with the rest of the library which is compiled without the pragma (because it has to communicate with COBOL and the rest of the world). I am considering doing the interface in Assembler. Does anybody have any experience and would share code snippets.Thank youZA Sent from Yahoo Mail on Android -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: interfacing between PL/I and C
Do i need the pragma in the C program if iuse the enterprize PLI. If this is not needed anymore then I am good. The types are non-issue, only the linkageThank youZA Sent from Yahoo Mail on Android On Tue, Feb 21, 2017 at 1:15 PM, Ze'ev Atlas<zatl...@yahoo.com> wrote: Hi all,I hope someone can guide me. I have a C library that I want to call from PL/I. I actually have to create an intrface module for some reasons. If I code it in C using #pragma linkage (..., PLI) I have no prlblem communicating between the C and the PL/I, but then the C cannot communicate with the rest of the library which is compiled without the pragma (because it has to communicate with COBOL and the rest of the world). I am considering doing the interface in Assembler. Does anybody have any experience and would share code snippets.Thank youZA Sent from Yahoo Mail on Android -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
interfacing between PL/I and C
Hi all,I hope someone can guide me. I have a C library that I want to call from PL/I. I actually have to create an intrface module for some reasons. If I code it in C using #pragma linkage (..., PLI) I have no prlblem communicating between the C and the PL/I, but then the C cannot communicate with the rest of the library which is compiled without the pragma (because it has to communicate with COBOL and the rest of the world). I am considering doing the interface in Assembler. Does anybody have any experience and would share code snippets.Thank youZA Sent from Yahoo Mail on Android -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PCRE2 for z/OS R21 is now available
PCRE2 for z/OS R21 is now available. Note that since PCRE2 is different then PCRE, it is available in a new location: file 939 on the CBT (CBTTAPE.ORG, file 939). The old PCRE would continue to be available on file 882. Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Rexx and member statistics question
Hi AllI have a Rexx program and here is the relevant snippet:
THEMEMBER = THEPDS || "(" || MEMBER || ")" /*say themember */
"alloc shr file(input) dataset(" THEMEMBER ")" "execio *
diskr input (stem input. finis)" IF RC \= 0 THEN
call DIE 'READ MEMBER failed' RC say member input.0
"LINES READ" "free file(input)"
"EXECIO" input.0 "DISKW XXOUT (STEM INPUT." IF RC \= 0 THEN
call DIE 'WRITE MEMBER failed' RC
Originally, I had "EXECIO * DISKW XXOUT (STEM INPUT."
but that would work only for members that had statistics (i.e. have been
updated). When I changed the '*' to input.0 it works fine. Is that a normal
behavior? (I ran on z/OS 2.2! Ze'ev Atlas
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx and member statistics question
You have it right There is no error message, the lines are just not written! ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx and member statistics question
I have to take it back In one of the libraries, I consistently have an empty line as the first line and I did do some of my tests on that library. Mystery resolved! Thank you all -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New Line vs. Line Feed
Gil is correct, \n is implementation dependent. Actually, PCRE handles it correctly, except that I've got confused and chose an incorrect option in my config.h. Once I've corrected it tests run smoothly and produce correct test results. Thanks all for explanations and advice ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New Line vs. Line Feed
Thank you all for comprehensive explanation ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New Line vs. Line Feed
Your messages clarified my issue and actually assured me that the solution I'd suggested is correct, so I would like to brief you. It is apparent that IBM chose to mark the end of line with NL and not with any of LF or CRLF. That on itself is probably a correct decision and probably what the standard should have been to begin with. The problem is that in the C language convention, the escape sequence \n has subtle double meaning. It means LF but it also contains within it the semantics of NL. When we do printf (some text \n); it will work correctly on all platforms and nobody would ever notice any problem. it will produce on EBCDIC some text NL and on ASCII platforms some text LF or some text CRLF But when we issue a pattern matching (I'll use Perl syntax for brevity) if ($text =~ /some text \n/) the \n is translated by convention to LF and the EBCDIC based pattern matching will fail to match! So the solution should be to somehow (optionally) dictate to the package that \n is NL and not LF. I've requested that such option would be implemented so I can use it. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
New Line vs. Line Feed
Hi allI am dealing with some C package on classic z/OS (PDS/E, no USS). When C reads text files it inserts 0x15 in the end of the record (it goes that far as to drop the trailing blanks and substitute them with one 0x15 for fixed length records, but I think that there is an option to override that). 0x15 is defined as New Line, but there is a separate character, 0x25 that is defined as Line Feed. Does anybody know why do we need two characters that seem to do the same thing (besides the evil desire to confuse the poor user :) Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PCRE 8.37 for classic z/OS is available
PCRE 8.37 for classic z/OS is available in CBTTAPE.ORG File882 and on zaconsultants.net Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Standard IBM Enterprise COBOL Service to convert ASCII to EBCDIC
Because in most cases programmers are less than lets say bright. Oh, I see... I guess that this is why my rate when I program in lowly Access VBA is higher then anything COBOL programmers could get. I am not even trying to compare that to my rate when I write Perl, T-SQL, PL/SQL, etc. They just assume that if I agree to program in COBOL. I must be, in your words, Less than bright. And that also explain why, by at large, there are not too many takers to the regular expression functionality that I promote in the COBOL world. What a sad statement. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Standard IBM Enterprise COBOL Service to convert ASCII to EBCDIC
to summarize the conversation: I don't know what is scarer letting ASCII loose in the environment or letting programmers know about it. Not to alarm you further, but I believe it's already endemic. Not in any company I have ever worked. Why is getting an ASCII piece of information so scary? And why would handling it using proper programming, any scary? So how would the companies you work for prevent the need? What would you do if you cannot allow FTP to do the conversion when there is a mix of alphanumeric characters and binary information? ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Standard IBM Enterprise COBOL Service to convert ASCII to EBCDIC
Thank you all to those who've pointed me to NATIONAL-OF and DISPLAY-OF intrinsic functions. For some reason I missed them when looking at the list of intrinsic functions. While calling the C runtime library is an interesting exercise, using native COBOL functionality when in COBOL is superior. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Announcing API copybooks between COBOL and the POSIX compliant regular expression standard functions
IBM provides standard POSIX compliant regular expression functions that are available both for classic z/OS and UNIX. Similarly, such services are available in all POSIX compliant Linux implementations. I gave developed a set of COPYBOOKS that provide standard API between COBOL and those services. My demo program compiles on IBM Enterprise COBOL 5.1 and demonstrates the use under classic z/OS. I attempted to create similar copybooks to use with GNU COBOL under Linux, but there appears to be a bug in GNU COBOL call sequence. The GNU COBOL team is aware about the situation and will try to fix the issue. The package is available on CBTTAPE, file 928 as well as on my website (zaconsultants.net) Ze'ev Atlas -- 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
Obviously, I know that and I realized that the issue is integral boundaries! I am dealing with COBOL, not PL/I but the real issue was that the order is the other way around (i.e. the fullword is first and the halfword is second, leaving a two bytes gap unaccounted for after every pair. So I resolved it by adding a dummy two bytes variable in the end of each pair: 10 A PIC 9(9) COMP-5. 10 B PIC 9(4) COMP-5. 10 FILLER PIC XX.=== compensating for the integral boundary of the next pair 10 D PIC 9(9) COMP-5. 10 E PIC 9(4) COMP-5. 10 FILLER PIC XX.=== compensating for the integral boundary of the next element This works fine. I still do not know how to make PL/I communicate with C, but COBOL and C communicate like a pair of newlyweds once this was resolved. ZA -- 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 guess I will use SYNC to ensure all integral boundaries... next release :) ZA -- 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
The SYNCHRONIZED clause is new to me (I do not code COBOL on regular basis any more.) I will incorporate that in the next release. Thanks to all who had suggested it ZA -- 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
Thanks Kolusu I will look into the PL/I interface for both this and the PCRE... maybe next release ZA -- 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
Re: A possible bug in the IBM Runtimne C library
Sure I could, but the geniuses who created the regex.h and friends did not deem that necessary, so the poor user has to go to the header file, read all the #if's and #else's and figure it our. Not an easy task when you are a COBOL poor user :( ZA -- 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 am going back to the drawing board and I will have a hard look at the regex.h again and will do some tests with 64 bits compilations vs. 32 bits. It is extremely hard to deduce from the documentation what to expect and what structure is in effect when one compiles with any combination of pragma's/macros, etc. Than, when I know better, I'll still have the task of apply that knowledge to COBOL compilation combination. I assume now that COBOL and C when compiled under normal LE environment communicate somehow with the library to produce the correct structures in reality. If I am correct, I just have to trace the rules and translate them to appropriate copybooks. I still think that the decision, many decades ago, to leave the actual definition and implementation of short, int, long, etc. to the implementation rather than enforce rules (16, 32, 64 bits) was wrong and shortsighted. I thought so when I was introduced to C in the late nineteen eighties and I did not find any reason to change my mind ever since. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Strange C runtime library behavior
Thank you all I am going back to the drawing board as I've mentioned on another thread ZA -- 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
One of the machines is rather old and one is much more current (1.6 vs 1.10 I believe but will check again tonight - I am only a user) I did it with COBOL 4.2 and 5.1 with same results. I do not remember the C compiler levels but the behavior was consistent, and WRONG in all combinations. I provided the C program in order to remove the complexity of C to COBOL interface. I would ask that somebody should check it on your machine (replace the DUMPMEM with printf in Hex). If it happens on your latest and greatest version, than I have a point. It does not matter whether the bug is in the library itself or in the language (C, COBOL, whatever) to library interface; I used the thing in the most common, no frills way, as is described in the manual, interfacing two different standard languages and got a problem. Either the manual is wrong or the library or the interface. It is clearly not a user programming issue. If anybody may overcome this issue by using some clever compile options than be it, but I do not think so! Ze'ev Atlas -- 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 am sorry for the typo, I was expecting (0,15),(2,8) and not (0,15),(8,2) long 0 long 15 long 2 long 8 I ran it in z/OS which should default to normal numbers so all classic LE languages would understand it correctly 19819478 | 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00 00 | 19819488 | 00 00 00 02 00 00 00 00 00 00 00 08 00 00 00 00 | However, your suggestion that For whatever reason, each long seems to be ordered as low order word followed by high order word. seems to answer the issue. If you are correct, then, the library provides an integer and a filler of 4 bytes. This explanation seems to be reasonable. Could anybody who is more C savvy and proficient with the runtime library usage, point to any proof that this is indeed the answer? Thanks ZA -- 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
Thank you for reposting The use of my_size was indeed wrong, so I dumped more than I needed. Only first two lines are relevant! I did not want to compile and run again because it was late at night I do not have access now, but the definition of regmatch_t is in the regex.h. Regardless of that definition, the library functions gives me back: 1 variable of 32 bits 3 variables of 64 bits I would not mind if I get 4 variables of 32 bits or 4 variables of 64 bits, I could handle each possibility, but the runtime consists of load modules and does not depend on my compile options. The library function may be super smart and communicate with my program based on how I compile it (32 or 64 bits) but it has to do it consistently! The problem is that the results are inconsistent and cannot be explained neither by what z/OS is used, nor by what language or compiler options are used. I ask again, please repeat my test and if you get same results, report it to IBM (I do not have any standing with IBM, but you may have!) ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A possible bug in the IBM Runtimne C library
Hi all
I suspect (and can prove that there is a bug in the regexec function. I have
encountered this issue on two z/OS systems with two different z/OS level. The
proof is repeatable and produce same wrong results any time.
To prove it I modified a sample C program from the IBM manual and added a call
for dumping memory (see below). The documentation and the regex.h declare that
the regmatch_t construct should be a pair of doublewords (long) and it is
supposed to be an element in an array of as many as you need. Iinstead of
getting two pairs of double words containing (0,15),(8,2), I get the first
component of the first element as one word (int) of 0 and the rest are indeed
double words. This seems like a bug in the runtime library.Here is the dump
(only the first two lines are relevant)
19819478 | 00 00 00 00 00 00 00 00 00 00 00 0F 00 00 00 00 |
19819488 | 00 00 00 02 00 00 00 00 00 00 00 08 00 00 00 00 |
19819498 | 00 00 00 40 00 00 00 00 10 00 00 00 19 81 92 48 |
ak198194A8 | 00 00 00 00 99 80 01 6E 04 C6 3C 98 00 00 00 00 | r K F q
I do not have contacts with IBM. Would any one of you please pick up the issue
with IBM so they can explain or fix it. I think that some people in IBM
monitor this list, so please, could you help.
Here is the program
#include regex.h
#include locale.h
#include stdio.h
#include stdlib.h
extern void DUMPMEM(char *address, int length);
#include zatoolib.h
main() {
regex_t preg;
char *string = a simple string;
char *pattern = .*(simple).*;
int rc;
size_t nmatch = 2;
regmatch_t pmatch[2];
int my_size = sizeof(pmatch)*2;
if ((rc = regcomp(preg, pattern, REG_EXTENDED)) != 0) {
printf(regcomp() failed, returning nonzero (%d)\n, rc);
exit(1);
}
if ((rc = regexec(preg, string, nmatch, pmatch, 0)) != 0) {
printf(failed to ERE match '%s' with '%s',returning %d.\n,
string, pattern, rc);
}
DUMPMEM ((char *)pmatch, my_size);
regfree(preg);
}
Ze'ev Atlas
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
need access to mainframe
Could anybody give me very limited remote access to a well configured z/OS development LPAR?All I need is to install few libraries and use the C and COBOL compilers and create some SYSOUT and perhaps few small sequential files and XMI files. All storage area I may need should never exceed 40MB. If you could, please contact me off list Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Strange C runtime library behavior
Hi allI am trying to create a common interface between COBOL and the runtime C library, especially the RegEx related functions. The regex.h header file indicates that the regmatch_t structure consists of two long variables (i.e. two pic s9(18) comp-5.). This structure is used as an element of an array of such elements for however reasonable amount needed.When I call the regexec function, it looks like the program returns as the first component of the first element only int (i.e. PIC s9(9) COMP-5.). All other components of that element and subsequent ones are correct. For example, I was supposed to get (0,15),(8,2)so I get 000F 0002 0008 instead of 000F 0002 0008 Does anybody have a clue about why do I get such a bizarre behavior. Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Announcing PCRE 8.36 port to native classic z/OS
Version 8.36 of PCRE (Perl Compatible Regular Expressions) library is now available on both CBTTAPE (www.cbttape.org) and on my website zaconsultants.net Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Announcing PCRE Pert for Classic z/OS 8.35 (Build 1499)
Announcing PCRE Port for Classic z/OS 8.35 (Build 1499) PCRE Port for Classic z/OS (Perl Compatible Regular Expressions) is now on a regular maintenance schedule, lagging only few months behind the main PCRE package version. The port is working with well defined scripts with minimal manual intervention. The port is available on my site http://zaconsultants.net/ and hopefully soon on http://www.cbttape.org/. The core documentation for PCRE is found as usual in http://www.pcre.org/pcre.txt . The Port documentation is part of the download file here www.zaconsultants.net/pcre_native_zOS_port.8.35.1499.zip The port includes the source code, JCL, LKED parameters, etc. and instructions on how to build it on any run-of-the-mill z/OS environment as well as XMIT formatted libraries (PDS and PDSE) that include the above, plus executables on a load module library that was compiled with codepage IBM-1047. The port is for classic z/OS. I know it would compile and work on z/VM, but the z/VM official support has been dropped. 1. While a few people have expressed interest in the PL/I interface and some tried to give me useful advice, I've found that with my limited time and resources, I cannot do it. Hence, PL/I support is officially dropped and will not be renewed unless there would be a volunteer who is both capable in working with PL/I and its interfaces, and is ready to devote time for this project. 2. Rexx seemed to me to be a perfect fit for PCRE. It is analogous to Perl in the native z/OS ecosystem and is doing similar (though much more primitive) pattern matching. However, the Rexx interface is extremely involved and working with it requires expertise that I do not posses and do not have the time to acquire, and that despite of useful advice from some people. Hence, no Rexx support is planned unless there would be a volunteer who is both capable in working with Rexx and its interfaces, and is ready to devote time for this project. Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PCRE for z/OS - a usage survey
I ported the PCRE - Perl Compatible Regular Expressions library to native classic z/OS about a year ago and kept up with maintenance. The current version on my website zaconsultants.net is 8.33. PCRE 8.34 has just been released and I am about to begin porting it to z/OS. There is a major change planned for next release that would raise it from 8.xx to 9.xx. Before I begin the undertaking of porting 8.34 and preparing for 9.xx I'd like to take some survey to gauge the usage of PCRE in our community. I know from anecdotal examination of my website logs, that there were few downloads, but I've not get any concrete feedback sans a feedback from one frustrated user in a very early release. I would appreciate any and all users of PCRE for z/OS to share your experience with me. Please drop a note to zatlas1 at yahoo dot com Ze'ev Atlas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Ze'ev appears to me to want to graft what are essentially interactive, conversational facilities onto JCL, which is a batch facility. This may well be possible, but doing it will require careful thought and much experimentation/evolutionary operation. I already concluded that the z/OS side may be hopeless because the limitations of file name are too entrenched in the OS. The Unix side (especially Linux that is open source) is a better candidate. No, I do not envision batch oriented only features. Once the file is committed in the traditional way (conversational or batch), its location would be known, so when you say in the shell (AND THIS IS ONLY ONE EXAMPLE): cp filename ~/myfolder/myappfolder filename will be found regardless of where it is. If filename is common among few files, the system may guess, using some algorithm (that indeed, needs much experimentation/evolutionary operation in its development) which one you need. Otherwise, you might be required to say (AND THIS IS ONLY ONE EXAMPLE): cp --ppath myapp1 --date 01/01/2013-02/15/2013 filename ~/myfolder/myappfolder If one bothers to give unique names and if the algorithm for dis-ambiguity would be good, the first example would prevail most of the time. Please forgive the yelling (AND THIS IS ONLY ONE EXAMPLE). While obviously we need people to question all possible details so they would be answered and thought about in the aforementioned algorithm. I do not want people to shoot the idea down just because I referred to only one example. I begin to have fun in toying this ides! ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Let me back it up a level: what's the problem you're trying to solve? Are you trying to make things more user-friendly? I submit that the unpredictability this introduces would have the opposite effect. This is the kind of reaction that I am waiting for, pointing to things that need to be answered rather than sticking with the existing model(s). I admit of not thinking the dis-ambiguity model through all the way yet (this conversation is my first attempt of expressing the issue). And unpredictability is for sure a show stopper. I will think about it and I ask anybody who may view this ideas as positive to think about it as well. Thanks ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
I still like using the Linux locate command for this. It does a data base lookup, which is maintained non-real-time via updatedb, and presents a list of entire path names which match the given input. I may need to look at getting the source and seeing if I can port it to z/OS UNIX. Locate/updatedb is probably the closest to what I want and we could base that functionality on it, but why can't we improve it to be yes-real-time? ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
That's correct and that's where I took the idea from. That concept needs improvements No doubt, but so far you haven't identified any defect that a new type of catalog would resolve. I have identified the defect pretty well, except that you refuse to see that definition and go to circular arguments about semantics! I will explain rather than define: In z/OS you are confined to 44 characters and limited to however many levels could be expressed within that limit, but you do not need to tell the system where the file resides because that information is stored in the catalog. In Unix, you do not have those length and level limitations, but you need to be explicit in describing where the file is or go through the trouble of creating symbolic links. Both sides are awkward, require too much memorization and each one has a glaring defect as identified above. With the envisioned catalog, file names are not limited in length or form, yet the system would know where do they reside. In case of two (or more) files that share the same name, a sophisticated implementation may either decide by context (e.g. a file that is owned by the requester would be preferred to file owned by somebody else - THIS IS ONLY AN EXAMPLE, PLEASE DO NOT GET INTO SEMANTICS), or ask to disambiguate (e.g. supply only one level that is different between the files - AGAIN, THIS IS ONLY AN EXAMPLE, PLEASE DO NOT GET INTO SEMANTICS) ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Mount point is dynamic, not static. Its more analogous to volser than to device address. Again, you discuss the shortcoming of a specific system while I have a broad view. Implementation would have to take things like volser, mount points or whatever and hide them once and for all from the user Once such a thing is implemented, all you need to do is mention the file name or alias, regardless of where in the system or file system you are. When I ask for 'SYS1.LINKLIB', which of my 20 SYS1.LINKLIB data sets do I get? There would always be the need to disambiguate. That need would either be answered either automatically by the system examining the context, or, and I've mentioned it, one may add hints to lead the system to the one file he or she needs. The example given by Shmuel is z/OS specific and if the user is sophisticated enough to need a specific SYS1.LINKLIB, he or she would probably be sophisticated enough to provide hinting information. Otherwise, whatever the system chooses is probably the correct one. For people who are not techno-geeks this is much simpler than anything available today. In what way is it simpler than the catalog and directory structures that currently exist? The ordinary user does not need to worry about creating user catalogs or about mounting file systems on empty directories. It's all transparrent to him. That's correct and that's where I took the idea from. That concept needs improvements which many in this conversation had alluded to. Another great idea from the z/OS that deserve implementation in that context (i.e. Central System Catalog) is the famous GDG. Whenever I explain the concept to my Unix friends they agree that such a brilliant idea should have been implemented in Unix as well. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Who is to say you can't have a alias DATASET name pointing to the real name like this: Index: /user/my/data- user.my.data You've just invented symbolic links! I pointedly did not refer to the symbolic links so far, but I see that I have to. All solutions that were suggested here are too much coupled to the Unix as we know it and/or point (correctly) to the limitation of the z/OS implementation. I am trying to look at the thing from a new point of view, totally free of the old concepts! What I envision is a central system catalog that any file name created (reasonably or virtually no limitations on file names, level of hierarchies or any other such limitations [obviously more, much more than 44 characters and 5 levels]) would be transparently cataloged into (by the kernel itself.) Obviously, that catalog entry would have to record (hard coded information such as volser, mounting point or whatever have you) where is that file resides in an absolute manner. Any moving of the file would be recorded there as well (regardless of what functionality is used to moves it!). If one wants to create an alias (perhaps a shorthand name for the file, symbolic link or whatever have you) that would also be in the central system catalog (with two way pointers between the entries.) Once such a thing is implemented, all you need to do is mention the file name or alias, regardless of where in the system or file system you are. If you have authority to access the file, you have it, period. Obviously, if same file name exists in more than one place, you must provide enough partial information to disambiguate and allow the system to locate that file. Such partial information could be something like: partial path creating user creating date or range etc. For people who are not techno-geeks this is much simpler than anything available today. I admit that I myself do not remember where my files are. I use 'Agent Ransack' on Windows and since Unix is not as user friendly, I keep many user variables of the various hierarchies. I don't like this. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
I interpreted little user as average Windows desktop user. I don't think Ze'ev was trying to be pejorative, just trying to indicate a person who isn't a techno-geek like most of us on the list. That's what I meant Thanks ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
how do you distinguish /u/myid/somefile.txt from /u/yourid/somefile.txt? Would the catalog have both entries? If so, then if you reference the file via this catalog, which file do you actually access? I did give some preliminary thought to this. To accommodate the current concepts of Unix (and Windows) hierarchical file system, such a catalog would, for sure, need to have entries for all files, distinguished by, not only file name, but also the absolute path, so the user could give partial path and find the file. Let's say (and this is common) you have a development and prod environments, which are different only by some branch: /aaa/bbb/dev/ccc/ddd/eee/fff/myfile vs. /aaa/bbb/prod/ggg/ddd/eee/fff/myfile a possible way to find that would be something like (I use backslash as the escape, in Windows we'll need to use slash :): \dev\myfile vs. \prod\myfile ore perhaps, in more complicated environments: \dev\ccc\myfile vs. \prod\ggg\myfile if the same file also exists in /aaa/bbb/dev/ppp/ddd/eee/fff/myfile and /aaa/bbb/prod/rrr/ddd/eee/fff/myfile this is only a concept and it comes to accommodate the peculiarities of the Unix file system. I may think of better ways to design the file systems of both OSes to begin with, but we all know about the hindsight vision. I did not give too much thought for the z/OS file naming because I know the situation there is much more hopeless. I am well aware about how the file naming scheme is entrenched in the rest of the OS. In that case Unix is much more flexible and could be adapted to some standard catalog use is such catalog would be developed and used. I actually gave a thought for the possibility of developing such a product, but I do not have the time and resources. I would be willing to advise and support anybody who may undertake such a project. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
I think you forgot the grin in that post, Gil. z/OS is not for the little user. Neither is UNIX (nor Linux). For a true little user, the OS of choice might be CP/M-80 on an Altair. Or maybe an Apple ][. grin/. It is Windows and now Android or iOS. all three have the same issues that I've discussed and a product to catalog files would be a boon for the 'little users' ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
From the little user point of view, he/she knows the name of the file. As a matter of policy in most facilities (probably all), all files that the little user do and/or care for are cataloged and are somewhere in the DFSMS managed storage. Thus, if he/she needs the file, all need to be done is mentioning the name. The 44 character name is indeed a stupid limitation that need to go away. The same thing about stupid limitation is the lack of standard catalog in Unix. That limitation needs to go away. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
I do not care so much about the actual implementation of the idea and its limitations. Surely, with two antiquated OSes like z/OS and Unix (form the nineteen sixties and seventies) there are limitations which both OS publishers dare or dare not (as it may be) correct. The issue is the concept, which, in my opinion, is better in the z/OS world. And the concept is that the computer should know where the file is, not the user. Thanks for the information about locate. I will surely use it. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS is antique WAS: Aging Sysprogs = Aging Farmers
Sorry abut using the word antiquated if it is perceived to be pejorative. I meant to point that both z/OS and Unix are pretty old (yet both are still useful and going strong:) Both have some nifty and some not so nifty ideas. To me, at the real world workplace, whenever I have to create environment variables that store very long directory hierarchy because I do not want to memorize that g-e, I wish again that the good ideas from the parallel world would make it to my current world. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL (was: Re: Aging Sysprogs = Aging Farmers)
Let me add another complains about JCL, it allows changing source code meaning in run time and sometimes this is hairy: //XXX DD DSN= // DCB=(LRECL=80,R //... The above is legit although I would fire anybody who doed it. R could be resolved to: // EXEC YYY,R='BLKSIZE=8000)' or it could be resolved to an early example of cose injection of your choice ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: aggressive drivers was: Interesting? How _compilers_ are compromising application security
What's the story about the name Kumuondanam Bimba? ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Aging Sysprogs = Aging Farmers
Robin Atwood said: Diverting the thread a tad, does anyone know where you can do an HLASM course? My young colleague wants to be inducted into the mysteries of the ancient craft and we found various IBM courses (see below) but none of them are currently being offered. Of course, various outfits are happy to come to your shop and give one-on-one instruction, but HR won't wear the expense of that. Don't misunderstand me, I do feel your pain, but let's examine some (tongue in cheek) alternatives :) 1. Print the Principles of Operation and the various current books about HLASM and let the poor soul read them! [I broke my teeth on the 360 POO and the 370 POO and even though English is not my native language, I had a pretty good command on what was said there. Years later IBM enhanced the books (i.e. farmed them out to 'professionals') so when it got to the ESA POO I began to look at the (then) new commands and the only thing I could've said was that the explanation was written in some dialect of English.] 2. Adopt the methodology of the Unix, Linux and Windows echosystems, abandon any assembly whatsoever, license C and write all code in that language. Some of the new guys (those that did not have Java as the only language) know that language from their collge days. That requires management to shell the money for C compiler (nobody on the mainframe needs that stuff!,) but that might be cheaper then the HR shelling money for training. If many places do that, then maybe we'd get a descent port of GCC after all. 3. If you go for alternative #2, then, I am ready to come to your site, take inventory and convert all Assembly code into either C or Cobol (I assume that if you have difficulties getting Assemler guys, PL/I [and PL/X] is next :( BTW, I listened to Larry Wall (of Perl fame) talking about the most important current languages. He discussed Java as the COBOL of the twenty first century, verbose... good point ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
Hi all While I may change my mind in the future, I've pretty much decided to abandon the project for now, for these reasons: 1. Mongo DB data is UTF-8 and not even ASCII. An EBCDIC version is thus irrelevant and not needed. This is different then the situation with the PCRE library where EBCDIC version is possible and useful in EBCDIC environment, and thus relevant. 2. Once the need for EBCDIC is ruled out, there is no real need for classic z/OS version. The C modules of the C driver could easily be compiled under USS and the only piece that might be needed is some COBOL copybooks and code to interface with the dll, resolve big and little endian conflicts and so on. This is a fairly easy task to do, but I sense that there is no specific need for it. As I've said, I may go back and do it some time in the future. 3. The most important obstacle is the fact that there is no descent development environment that could be reasonably and legally available to open source developers. This, combined with the hostility towards C in classic z/OS shops, curtails the ability of many potential users to actually build from source code and the ability of the project to distribute binaries. I will concentrate my open source efforts elsewhere ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Interested in up to date open source software or low cost utilities?
because they do not have C and cannot build it. Isn't PCRE written in C? Yes, and that's why I had to provide binaries which is NOT ideal, because the binaries are IBM1047 specific ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
Who's using F1? MongoDB is currently valued at $1B and has venture capatalists throwing money at it. Last time I looked Mongo could handle joins and complex data and had a very rich query language. F1 is obviously new and it is not clear how (if at all) Google would release it for non-Google users, but it is a fact that one of the largest big data users in the world felt the need for such a thing. Mongo could handle joins in a forced non-natural way which they call embedded documents and linking. This is akin to what is done in IMS. Don't misunderstand me, Mongo has its uses, but OLTP is decidedly not one of them. The flatter the data model in Mongo, the better you realize its benefits. Again, for complex data models you would want something better. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Language development cycle (Perl)
I liked how Larry defined Java as the COBOL of the 21st century. It is so true ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
Is SQL really that much better then native APIs? In the case of your typical key/value data store surely get/set is easier than SELECT FROM WHERE/UPDATE SET IN etc. My short answer would be YES! The Typical key/value data store may be better handled with get/set. But presenting complex data (think OLTP) in those data stores is pretty much impossible. The hierarchical databases like IMS and IDMS (multi-hierarchies) were an interesting solution that used API to navigate the hierarchies [and I did a lot of work in both.] However, ultimately, in any real world application that is beyond what you could handle in flat Excel like store or Typical key/value data store, you find the need for relations... and the relational model. Typical key/value data store with some forced relations may be good for warehouse type of application. Anything else need some relational model, and SQL engines are pretty refined and do the navigation for you. My reason of thinking about interfacing MongoDB to COBOL is the fact that COBOL is very well suited to deal with API's and the hierarchical model. And I believe that MongoDB has its place as Warehouse engine. Again, even in the Big Data movement there is now a tendency to go back to SQL, hence Google's F1 Database engine. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Interested in up to date open source software or low cost utilities?
Bob Wrote: The open source Linux tools generally require porting, which require a mainframe, which most folks don't have at home, so open source isn't significant in the mainframe arena. This is the main issue really, getting a descent and legitimate development environment is tough. And then there is another, related subject, most open source is written in C which is NOT available in many many shops. It is a legitimate, fully developed and wonderful compiler in z/OS but it cost money and many shops just don't spend that money. So even if you go through the trouble of porting the open source into Classic z/OS (PDSE's, JCL, at al) as I did when I ported the PCRE library, it's not good enough because many potential users cannot build it anyway. Providing binaries might have been a solution had we not have to deal with the bizarre EBCDIC issue. The issue is not so much that EBCDIC is different then ASCII, that is relatively easy to handle. The issue is that if you provide a binary for IBM-1047 it surely won't work on a IBM-1026 Turkish or Greek or any other language. Bottom line, the port as well as it done is basically unavailable. I am pretty disappointed because I really wanted to start a trend. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
I will look carefully at the Java option and JNI, but my inclination (as an old timer) is to adapt the C driver rather. Working directly with C subroutines from COBOL, without a Java layer seems to me to be more natural, but again, I am an old timer and I do not really know Java. If I need extensive additional functionality, not available in the driver, than that could be a reason to do Java (and learn that stuff at long last; I love working with languages that I don't know.) Can somebody please point me to the documentation of JNI and interfacing Java and COBOL. I did not yet look at the N type and the limitation that have been mentioned here (only 80 characters) would be a make or break. If indeed I cannot reasonably deal with (virtually) unlimited UTF-8 strings then I will not even start the porting project. My time and resources are limited! ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
The compiler limitations are for LITERALS, not for variables. Think VALUE clause, or constant strings MOVEd to a variable. That's good news ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Is there currently a way to access MongoDB from z/OS LE languages?
Hi all Is there currently a way to access MongoDB from z/OS LE languages? ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
It should be simple enough to build a client. There are many http://docs.mongodb.org/ecosystem/drivers/. Of course, that's for accessing MongoDB running off the mainframe. I'm interested to know why you would want to do that? I have no intention on porting the whole engine because I understand the difficulties, but allowing COBOL to access MongoDB on some MongoDB cluster is not different (conceptually) from accessing any other remote database. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
EBCDIC may not be your only problem! What about endianess? I suggest you study the wire protocol if you are serious thank you for pointing me to the right direction. I will look at the documents you've mentioned about both, EBCDIC and endianess and see if it it worth it. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
It's not much fun accessing Mongo in C let alone COBOL. Agree My language of choice is Perl which flaws with that stuff and I am working on my JavaScript skills. However, what drives me is frustration. Whenever I do a mainframe project, I see how much I miss the other side's features and then I look how to bring those features in. I may need to invent a way to represent complex key value structures in COBOL which is a challenge on its own (unless somebody has already done it.) The simplest solution would be a two dimensional table of Z type strings, but that would not allow in a simple way for hierarchies. I guess I'll have to develop a type and the functionality to handle it. About a previous post, the endianess should not be a big issue to deal with once the two sides of the protocol are well defined. The EBCDIC issue is a make or break issue. MongoDB works decidedly with UTDF-8 and I need COBOL to natively view a string as UTF-8. Does the current incarnation of COBOL (and perhaps PL/I) have a native UTF-8 string type. If not, then I will abandon the whole project. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
Actually, it looks like there is support to UTF-8: ___ You need to do two steps to convert ASCII or EBCDIC data to UTF-8: Use the function NATIONAL-OF to convert the ASCII or EBCDIC string to a national (UTF-16) string. Use the function DISPLAY-OF to convert the national string to UTF-8. ___ This is from Enterprise COBOL for z/OS Version 5.1 documentation and there is N type. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MongoDB
Since NoSQL seems to be reigning supreme, I decided to study MongoDB which was both recommended by a friend (a PM who is managing an actual project with that stuff) and is the most popular NoSQL engine out there according to http://db-engines.com/en/ranking (they don't count Hadoop since they considered it to be a file system.) As usual, I acquired the book (O'Reilly - mongodb the definitive guide) and began to read... And here is why I post it here, I have the sense of deja vu all over again! Forget about the fancy terminology of storing Documents rather then rows or records. In the end it is the same. They have all the CRUD actions (i.e. Create, Remove, Update and Delete) which are done via some API functions rather then SQL statements. They can index and access stuff fast. They can partition the database over many servers and thus scale out... all is good. But here is the real scoop! No Joins and if you want to store some row... er... document of different structure that relate to the current one, you'd rather store it as a sub document (i.e. a different structure that is part of your current row (i.e. hierarchical) or in a different collection that you should navigate into in the application side. Mmm, have I just used the words navigate, hierarchical, etc. No wonder that all those younger people are so excited about NoSQL, they have never seen it before. But we, veterans of IMS, IDMS, ADABAS and the like, our old skills are new again! Welcome back to the future. BTW, I do not bad mouth the technology, it is very useful (as were IMS and IDMS) and I can see replacing all warehouses and Star Schemas with that stuff, it is more natural, faster and more scalable then the current SQL based warehouse technologies. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MongoDB
Oh No, It is much more then that. You store a set of key-values, which means that the dictionary (metadata) is part of the row. If you know Perl or Java you actually store hashes (or objects) which they call documents ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MongoDB
In Rexx, you could think about it as storing a stem ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MongoDB
Dave Caryford said: It is not, however, a drop in replacement for traditional transactional data bases. You are correct, it IS not and SHOULD never be used as a transnational database. It is however, a great (read better, more natural, more scalable, etc.) replacement to warehoses with star schemas and the like. Conceptually, navigating MongoDB is similar to navigating IMS and IDMS and is totally different then using relational sets (using SQL) 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'
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'
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. 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'
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
Announcing PCRE for z/OS 8.33 V2
PCRE for z/OS 8.33 V2 is nnow available on my website www.zaconsultants.net. New in this version: Full support for the Posix compatibility module GETMAIN and FREEMAIN as front ends for malloc and free pcregrep version that recognizes PDS and PDSE as such and treat them as directories and full support for HFS and ZFS With all the limitations of PCREGREP, I could still say SRCHFOR is dead, long live PCREGREP. 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'
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: REXX exec, To compile or not to compile
Yes if you have a lot of rexx-pure executing code. If you have a many host commands intermingled with the code it's probably not much benefits. I wanted to ask, where is EXECIO in the picture and how is it compares with using stream Thanks ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
