Re: Sharing ZFS file b/w two systems [not sysplex]
Thanks john, I also read about RECATALOG parm. The restriction is if the HLQ is not SYS1 then the catalog name must match for RECATALOGing. I made a plan based on this. 1)make the ZFS filesystem as READONLY in SYS1 AUTOMOVE=YES 2)Define a UCAT in SYS1 same name as the MCAT of SYS2 (since my HLQ for ZFS is not SYS1) 3)Define cluster with same name of original ZFS in SYS1 with RECATALOG. 4)MOUNT ZFS FS as R/W in SYS1 5)APPLY maintenance, then unmount. 6)delete Cluster with noscratch. Delete the UCAT (or keep it for future) 7)Make the FS R/W in SYS1 Going to try this on a sample ZFS on Monday Thanks and Regards Shameem K Shoukath From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, July 26, 2013 6:00 PM Subject: Re: Sharing ZFS file b/w two systems [not sysplex] You can only do this if the ZFS file is NOT, NOT, NOT currently mount in Read/Write mode on System1. You cannot access a VSAM file (and a zFS container dataset is a VSAM LINEAR data set) which is not catalogued. If the zFS DSN has a high level node of SYS1, then you _CAN_ simply catalog it in System2's master catalog using a RECATALOG parameter on the DEFINE for it. If it is not SYS1, you can't do this. I don't know why IBM allows this, but they do. Another, strange, possibility is to NFS export the mount point from System1 and then MOUNT the exported filesystem somewhere on System2. But this requires that you have NFS running on both systems. Well, NFS server running on System1 and NFS client running on System2. No, don't ask me how. I know it is possible, but I have some sort of mental block about it because I've never gotten it to work properly. On Fri, Jul 26, 2013 at 9:04 AM, Shameem .K .Shoukath shameemkshouk...@yahoo.com wrote: hi, There are two different systems LPARs on the same box and volumes can be made online on both sides. I have a ZFS file on System1 on VOLUM1 cataloged in master cat and it belong there. I need the same ZFS file on SYStem 2 temporarily to apply some maintenance (SMPE). What would be the best way to do this? I am trying to avoid import connect SYS2 mcat catalog to SYS1 master catalog any ideas ? Thanks Shameem -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Writing binary VB files in C
Am I correct in my reading of the C manuals? (I find the information somewhat scattered and oddly organized.) If I want to write a typical old-fashioned z/OS dataset in format VB and that contains binary fields in a field-oriented record layout, then (1) my only choice is to use fwrite() (or one of its variants) and (2) I would declare the struct and construct the record *without* the llbb control word and specify the length of the record (without the llbb) only in the fwrite()? Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
It's not formatted terrifically for copying and pasting here but LONGLONG shows up in the listing as one of the suboptions of LANGLVL under Compiler Options. LANGLVL(ANONSTRUCT,ANONUNION,ANSIFOR,ANSISINIT,NOAUTOTYPEDEDUCTION,C99VLA,C9 9__F NOC99LONGLONG,NOC99PREPROCESSOR,NOCOMPATRVALUEBINDING,NODBCS,NODECLTYPE,NODE LEGA DEPENDENTBASELOOKUP,NODOLLARINNAMES,EMPTYSTRUCT,NOEXTENDEDFRIEND,NOEXTENDEDI NTEG EXTERNTEMPLATE,ILLPTOM,IMPLICITINT,NOINLINENAMESPACE,LIBEXT,LONGLONG,NONEWEX CP,O NOOLDDIGRAPH,OLDFRIEND,NOOLDMATH,NOOLDSTR,OLDTEMPACC,NOOLDTMPLALIGN,OLDTMPLS PEC, NOTEMPSASLOCALS,NOTEXTAFTERENDIF,GNU_LABELVALUE,GNU_COMPUTEDGOTO,TRAILENUM,T YPED VARARGMACROS,NOVARIADICTEMPLATES,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99COMPLEX, NOC9 NOGNU_COMPLEX,GNU_SUFFIXIJ) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, July 25, 2013 7:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem I think I see your problem. Try compiling with LANGLVL(LONGLONG). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Writing binary VB files in C
On Sat, Jul 27, 2013 at 4:52 AM, Charles Mills charl...@mcn.org wrote: Am I correct in my reading of the C manuals? (I find the information somewhat scattered and oddly organized.) If I want to write a typical old-fashioned z/OS dataset in format VB and that contains binary fields in a field-oriented record layout, then (1) my only choice is to use fwrite() (or one of its variants) and (2) I would declare the struct and construct the record *without* the llbb control word and specify the length of the record (without the llbb) only in the fwrite()? you are correct. The fopen needs to specific wb, type=record or wb,type=record,recfm=* or some other variant with the lrecl and blksize specified if you want to control the dcb attributes from within your program. The important part is the wb and type=record. Then the fwrite needs to specify the size to 1 and the count to the lenth of the record not including the RDW length. for example fwrite( structure, 1, recordLentth, outFile); //where recordLength = amount of data to write. If recordLength lrecl of file, record is truncated. See chapter 3 in the C/C++ Run-Time Library Reference SA22-7821 for details about fwrite Also see chapter 10 in the C/C++ Programming Guide SC09-4765 for details on OS I/O operations. If there is no requirement to reposition the file using fseek, etc., include the noseek parameter in the call to fopen. Charles -- 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: Looking for help with an obscure C integer problem
If this were a problem that I had to solve, I would now contact IBM support and tell them that in the second call to ffs the compiler always puts a zero argument into the call argument list, although it should put the result of the 32 bit right shift there. There is clear evidence for this from the ASSEMBLER resolution that you posted yesterday. This is a compiler bug IMHO. There were no differing opinions from others so far. Kind regards Bernd Am 27.07.2013 13:59, schrieb Charles Mills: It's not formatted terrifically for copying and pasting here but LONGLONG shows up in the listing as one of the suboptions of LANGLVL under Compiler Options. LANGLVL(ANONSTRUCT,ANONUNION,ANSIFOR,ANSISINIT,NOAUTOTYPEDEDUCTION,C99VLA,C9 9__F NOC99LONGLONG,NOC99PREPROCESSOR,NOCOMPATRVALUEBINDING,NODBCS,NODECLTYPE,NODE LEGA DEPENDENTBASELOOKUP,NODOLLARINNAMES,EMPTYSTRUCT,NOEXTENDEDFRIEND,NOEXTENDEDI NTEG EXTERNTEMPLATE,ILLPTOM,IMPLICITINT,NOINLINENAMESPACE,LIBEXT,LONGLONG,NONEWEX CP,O NOOLDDIGRAPH,OLDFRIEND,NOOLDMATH,NOOLDSTR,OLDTEMPACC,NOOLDTMPLALIGN,OLDTMPLS PEC, NOTEMPSASLOCALS,NOTEXTAFTERENDIF,GNU_LABELVALUE,GNU_COMPUTEDGOTO,TRAILENUM,T YPED VARARGMACROS,NOVARIADICTEMPLATES,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99COMPLEX, NOC9 NOGNU_COMPLEX,GNU_SUFFIXIJ) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, July 25, 2013 7:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem I think I see your problem. Try compiling with LANGLVL(LONGLONG). -- 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: Establishing and using Unix file system and USS under z/OS
I think you should abandon the idea of trying to replicate perl syntax. Perl makes me want to hurl, it's user hostile. I just copied the API functions like match, search, replace and implemented a command for each one. I could and should have added functionality to process an entire stem array or file for efficiency. On 27/07/2013, at 12:09 AM, John McKown john.archie.mck...@gmail.com wrote: I remember and have kept the notes. But the problem is designing the command set to be implemented for the ADDRESS PCRE subcommand environment. E.g. ADDRESS PCRE (REXXVAR)=~s/[^[:print:]]/ /g /* translate unprintables to blanks in place*/ (NEWVAR)=(REXXVAR)~/s/[^[:print:]]/ /g /* translate unprintables to blanks and put the results in NEWVAR But is that a good syntax? I'm not sure. It may be too Perl-like for REXX people. On Fri, Jul 26, 2013 at 8:35 AM, David Crayford dcrayf...@gmail.com wrote: I described how I did this a few weeks ago. I wrote two assembler programs, the first to create the command enviroment(IRXSUBCM) and initialize a persistent LE environment (CEEPIPI). There is a user token in the SUBCM control block where you can store state, like the PIPI handle. The second one just grabs the PIPI handle from the user control block and calls a C++ program to do the fancy stuff. I used the C++ TR1 regex library so it supports lots of different flavours of regex - basic, extended, ECMAScript, awk, grep and egrep.|| ECMAScript is almost identical to PCRE but not quite as good. Have fun. On 26/07/2013 8:01 PM, John McKown wrote: Yes, I have a guest account for this project. The plus of using HLASM and CEEPIPI is that I can keep the LE environment active even when the HLASM interface program returns to REXX. If I use a C main routine, unless I am mistaken, that when it returns, the LE environment will be destroyed. Being the weirdo that I am, I try to save every millisecond of CPU that I can. So using HLASM / CEEPIPI might result in a fair amount of savings if someone uses the interface heavily in some REXX routine. What I'm trying to figure out how to do is something akin to what ISPF and SDSF do with their ADDRESS ISPEXEC and ADDRESS SDSF. I want to create an ADDRESS PCRE. But I've ever and only been a sysprog. Not a developer. I can develop code fairly well. But doing _design_, especially on a conceptual level, is not a strong skill of mine. On Fri, Jul 26, 2013 at 3:52 AM, David Crayford dcrayf...@gmail.com wrote: On 26/07/2013 9:56 AM, John McKown wrote: I'm still trying to look at how I might due a REXX interface to PCRE. But I'm not sleeping well due to a sick dog and so just don't have much extra energy after work. I do now have access to a remote system with a C license. But I might actually find it easier to us HLASM and a CEEPIPI environment, rather than C. John, bite the bullet and hack a bit of C. It's easy, especially if you already know assembler! Did some kind soul offer the use of their system? On Jul 25, 2013 8:43 PM, Ze'ev Atlas zatl...@yahoo.com wrote: Gentlemen The example and explanations are exactly what I needed to give me the head start (and now I can go to the manual and have some better understanding of details if I need them :) I caught the SYSUT1/SYSUT2 issue and assumed right away that it was a typo. Thank you so much Now - with your help, adding the functionality of deciding what type of file I am looking at (using fldata) and sending it to the correct piece of code seems much less intimidating. HFS files and flat files will pretty much go to the existing Unix oriented code and dealing with PDS is pretty much coded and tested. I will try to code the additional functions in most generic way and since it is open source, it probably could be used all over. It will be shipped with the next version of PCRE for z/OS project. Ze'ev Atlas PCRE for z/OS Open Source project Volunteers are welcome Still in need for analyzing, designing and implementing Rexx interface! --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --**--** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --** --**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test
Re: Looking for help with an obscure C integer problem
last bug I reported I invested hours and hours and ultimately received zero benefit. Charles Composed on a mobile: please excuse my brevity Bernd Oppolzer bernd.oppol...@t-online.de wrote: If this were a problem that I had to solve, I would now contact IBM support and tell them that in the second call to ffs the compiler always puts a zero argument into the call argument list, although it should put the result of the 32 bit right shift there. There is clear evidence for this from the ASSEMBLER resolution that you posted yesterday. This is a compiler bug IMHO. There were no differing opinions from others so far. Kind regards Bernd Am 27.07.2013 13:59, schrieb Charles Mills: It's not formatted terrifically for copying and pasting here but LONGLONG shows up in the listing as one of the suboptions of LANGLVL under Compiler Options. LANGLVL(ANONSTRUCT,ANONUNION,ANSIFOR,ANSISINIT,NOAUTOTYPEDEDUCTION,C99VLA,C9 9__F NOC99LONGLONG,NOC99PREPROCESSOR,NOCOMPATRVALUEBINDING,NODBCS,NODECLTYPE,NODE LEGA DEPENDENTBASELOOKUP,NODOLLARINNAMES,EMPTYSTRUCT,NOEXTENDEDFRIEND,NOEXTENDEDI NTEG EXTERNTEMPLATE,ILLPTOM,IMPLICITINT,NOINLINENAMESPACE,LIBEXT,LONGLONG,NONEWEX CP,O NOOLDDIGRAPH,OLDFRIEND,NOOLDMATH,NOOLDSTR,OLDTEMPACC,NOOLDTMPLALIGN,OLDTMPLS PEC, NOTEMPSASLOCALS,NOTEXTAFTERENDIF,GNU_LABELVALUE,GNU_COMPUTEDGOTO,TRAILENUM,T YPED VARARGMACROS,NOVARIADICTEMPLATES,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99COMPLEX, NOC9 NOGNU_COMPLEX,GNU_SUFFIXIJ) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, July 25, 2013 7:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem I think I see your problem. Try compiling with LANGLVL(LONGLONG). -- 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: Writing binary VB files in C
Perfect. Thanks much. Charles Composed on a mobile: please excuse my brevity Sam Siegel s...@pscsi.net wrote: On Sat, Jul 27, 2013 at 4:52 AM, Charles Mills charl...@mcn.org wrote: Am I correct in my reading of the C manuals? (I find the information somewhat scattered and oddly organized.) If I want to write a typical old-fashioned z/OS dataset in format VB and that contains binary fields in a field-oriented record layout, then (1) my only choice is to use fwrite() (or one of its variants) and (2) I would declare the struct and construct the record *without* the llbb control word and specify the length of the record (without the llbb) only in the fwrite()? you are correct. The fopen needs to specific wb, type=record or wb,type=record,recfm=* or some other variant with the lrecl and blksize specified if you want to control the dcb attributes from within your program. The important part is the wb and type=record. Then the fwrite needs to specify the size to 1 and the count to the lenth of the record not including the RDW length. for example fwrite( structure, 1, recordLentth, outFile); //where recordLength = amount of data to write. If recordLength lrecl of file, record is truncated. See chapter 3 in the C/C++ Run-Time Library Reference SA22-7821 for details about fwrite Also see chapter 10 in the C/C++ Programming Guide SC09-4765 for details on OS I/O operations. If there is no requirement to reposition the file using fseek, etc., include the noseek parameter in the call to fopen. Charles -- 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: Looking for help with an obscure C integer problem
don't know for C, but for problems or questions concerning the PL/1 compiler, IBM support was always very responsive and helpful. That's my experience, at least. You could help them by isolating the problem with a small test program (containing for example only this function and a little main with a test call). Provide the compile list with the LIST option, together with the problem description. Kind regards Bernd Am 27.07.2013 16:21, schrieb Charles Mills: last bug I reported I invested hours and hours and ultimately received zero benefit. Charles Composed on a mobile: please excuse my brevity Bernd Oppolzer bernd.oppol...@t-online.de wrote: If this were a problem that I had to solve, I would now contact IBM support and tell them that in the second call to ffs the compiler always puts a zero argument into the call argument list, although it should put the result of the 32 bit right shift there. There is clear evidence for this from the ASSEMBLER resolution that you posted yesterday. This is a compiler bug IMHO. There were no differing opinions from others so far. Kind regards Bernd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Establishing and using Unix file system and USS under z/OS
David Crayford wrote: begin extract I think you should abandon the idea of trying to replicate perl syntax. Perl makes me want to hurl, it's user hostile. /end extract I agree strongly with his recommendation [without necesarily agreeing with his judgment of the 'absolute' merits Perl's syntax]. The problem here is, I think, one of concordance or coherence. Anyone who knows something of a statement-level language should be able to make plausible, almost invariably confirmed conjectures about how the rest of it goes; and mixing syntactic sugars defeats this. The syntax of ALL non-assignment PL/I and REXX statements, CICS commands, and some but not all IBM utilities is the same simple, well understood one. Lexical breakout is thus the same for any and all such statements, and token parsing can be table-driven. In a REXX environment it is better and much easier to stick to it. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
I was able to reproduce the problem with a little test program:
#include stdio.h
#include stdlib.h
static void longtest (long long lwert)
{
int test;
test = lwert 0xLL;
if (test != 0)
{
printf (lwert right = %x\n, test);
}
else
{
test = lwert 32;
printf (lwert left = %x\n, test);
}
}
int main (void)
{
long long lwert;
int l1;
int l2;
int *p;
char zeile [85];
fgets (zeile, 80, stdin);
l1 = atoi (zeile);
fgets (zeile, 80, stdin);
l2 = atoi (zeile);
lwert = l1;
lwert = 32;
lwert += l2;
p = (int *) (lwert);
printf (long long first part = %x\n, *p);
printf (long long second part = %x\n, *(p + 1));
longtest (lwert);
}
this was compiled using z/OS XL C version 1.11.
The error only showed up when using the compile option HGPR,
that is, when the compiler used the G-instructions, like SRAG etc.
results with HGPR:
long long first part = 8000
long long second part = 0
lwert left = 0
results without HGPR:
long long first part = 8000
long long second part = 0
lwert left = 8000
this can be confirmed by looking at the ASSEMBLER code generated in both
cases:
with HGPR:
* longtest (lwert);
LG r0,lwert(,r13,304)
ST r0,lwert%2=1(,r13,316)
TEST LONG LONG:
SRAG r0,r0,32
ST r0,lwert%2=1(,r13,312)
+ LG r0,lwert%2=1(,r13,312)
+ LTR r0,r0
+ BE @1L6
+ LA r1,+CONSTANT_AREA(,r2,55)
+ ST r0,#MX_TEMP1(,r13,228)
+ LGF r15,=V(PRINTF)(,r3,362)
+ ST r1,#MX_TEMP1(,r13,224)
+ LA r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS 0H
+ LA r0,+CONSTANT_AREA(,r2,73)
+ ST r0,#MX_TEMP1(,r13,224)
+ LGHI r0,H'0'
+ LGF r15,=V(PRINTF)(,r3,362)
+ LA r1,#MX_TEMP1(,r13,224)
+ ST r0,#MX_TEMP1(,r13,228)
+ BASR r14,r15
+@1L7 DS 0H
without HGPR:
* longtest (lwert);
Lr4,a1:d240:l4(,r13,240)
TEST LONG LONG:
ICM r0,b'',a1:d244:l4(r13,244
+ BE @1L6
+ LA r1,+CONSTANT_AREA(,r2,55)
+ ST r0,#MX_TEMP1(,r13,228)
+ Lr15,=V(PRINTF)(,r3,302)
+ ST r1,#MX_TEMP1(,r13,224)
+ LA r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS 0H
+ LA r0,+CONSTANT_AREA(,r2,73)
+ LA r5,0
+ ST r0,#MX_TEMP1(,r13,224)
+ SRDA r4,32
+ Lr15,=V(PRINTF)(,r3,302)
+ ST r5,#MX_TEMP1(,r13,228)
+ LA r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+@1L7 DS 0H
* }
LA r15,0
look at the SRDA instrunction, which is missing in the other case.
This is a compiler error and should be repaired by IBM support.
Kind regards
Bernd
Am 27.07.2013 17:03, schrieb Bernd Oppolzer:
don't know for C, but for problems or questions concerning
the PL/1 compiler, IBM support was always very responsive
and helpful. That's my experience, at least.
You could help them by isolating the problem with a small
test program (containing for example only this function and
a little main with a test call). Provide the compile list
with the LIST option, together with the problem description.
Kind regards
Bernd
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The Rubicon has been crossed: no more hardcopy IBM publications from the IBM Publications Center
I especially want to purchase a hard copy of the Principles of Operation. I think it is around $1,600 per copy now. Yeah! That's the ticket. Bill Fairchild Franklin, TN - Original Message - From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 23, 2013 6:05:35 PM Subject: Re: The Rubicon has been crossed: no more hardcopy IBM publications from the IBM Publications Center Or order the PDF and have FedEx/Kinkos or the equivalent print it. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Tuesday, July 23, 2013 5:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: The Rubicon has been crossed: no more hardcopy IBM publications from the IBM Publications Center While downloading something else at the IBM Publications Center I found the notice: begin copy Effective July 29th 2013: According to e-Business strategy, IBM Publications Center does'nt support ordering anymore. The Publications are being made available in electronic format to be viewed or downloaded free of charge. /end copy If you judge that you need a hardcopy version of a manual, order it during the next few days. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
Charles, You are a vendor and may have found a problem with the C integer process. It would be of benefit to the community when you find something like this to report even if you do not get benefit directly. Instead you get an indirect benefit of helping the community and preventing someone else hours of searching and testing. If there was something wrong with one of your processes, would you want your customer to say - it is not worth it. Or would you want it reported so you can fix it. Just my 2 cents worth Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Saturday, July 27, 2013 7:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem last bug I reported I invested hours and hours and ultimately received zero benefit. Charles Composed on a mobile: please excuse my brevity Bernd Oppolzer bernd.oppol...@t-online.de wrote: If this were a problem that I had to solve, I would now contact IBM support and tell them that in the second call to ffs the compiler always puts a zero argument into the call argument list, although it should put the result of the 32 bit right shift there. There is clear evidence for this from the ASSEMBLER resolution that you posted yesterday. This is a compiler bug IMHO. There were no differing opinions from others so far. Kind regards Bernd Am 27.07.2013 13:59, schrieb Charles Mills: It's not formatted terrifically for copying and pasting here but LONGLONG shows up in the listing as one of the suboptions of LANGLVL under Compiler Options. LANGLVL(ANONSTRUCT,ANONUNION,ANSIFOR,ANSISINIT,NOAUTOTYPEDEDUCTION,C9 9VLA,C9 9__F NOC99LONGLONG,NOC99PREPROCESSOR,NOCOMPATRVALUEBINDING,NODBCS,NODECLTY PE,NODE LEGA DEPENDENTBASELOOKUP,NODOLLARINNAMES,EMPTYSTRUCT,NOEXTENDEDFRIEND,NOEX TENDEDI NTEG EXTERNTEMPLATE,ILLPTOM,IMPLICITINT,NOINLINENAMESPACE,LIBEXT,LONGLONG, NONEWEX CP,O NOOLDDIGRAPH,OLDFRIEND,NOOLDMATH,NOOLDSTR,OLDTEMPACC,NOOLDTMPLALIGN,O LDTMPLS PEC, NOTEMPSASLOCALS,NOTEXTAFTERENDIF,GNU_LABELVALUE,GNU_COMPUTEDGOTO,TRAI LENUM,T YPED VARARGMACROS,NOVARIADICTEMPLATES,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99C OMPLEX, NOC9 NOGNU_COMPLEX,GNU_SUFFIXIJ) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, July 25, 2013 7:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem I think I see your problem. Try compiling with LANGLVL(LONGLONG). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
I hear you. If I get the time I will explain my thoughts. Charles Composed on a mobile: please excuse my brevity Lizette Koehler stars...@mindspring.com wrote: Charles, You are a vendor and may have found a problem with the C integer process. It would be of benefit to the community when you find something like this to report even if you do not get benefit directly. Instead you get an indirect benefit of helping the community and preventing someone else hours of searching and testing. If there was something wrong with one of your processes, would you want your customer to say - it is not worth it. Or would you want it reported so you can fix it. Just my 2 cents worth Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Saturday, July 27, 2013 7:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem last bug I reported I invested hours and hours and ultimately received zero benefit. Charles Composed on a mobile: please excuse my brevity Bernd Oppolzer bernd.oppol...@t-online.de wrote: If this were a problem that I had to solve, I would now contact IBM support and tell them that in the second call to ffs the compiler always puts a zero argument into the call argument list, although it should put the result of the 32 bit right shift there. There is clear evidence for this from the ASSEMBLER resolution that you posted yesterday. This is a compiler bug IMHO. There were no differing opinions from others so far. Kind regards Bernd Am 27.07.2013 13:59, schrieb Charles Mills: It's not formatted terrifically for copying and pasting here but LONGLONG shows up in the listing as one of the suboptions of LANGLVL under Compiler Options. LANGLVL(ANONSTRUCT,ANONUNION,ANSIFOR,ANSISINIT,NOAUTOTYPEDEDUCTION,C9 9VLA,C9 9__F NOC99LONGLONG,NOC99PREPROCESSOR,NOCOMPATRVALUEBINDING,NODBCS,NODECLTY PE,NODE LEGA DEPENDENTBASELOOKUP,NODOLLARINNAMES,EMPTYSTRUCT,NOEXTENDEDFRIEND,NOEX TENDEDI NTEG EXTERNTEMPLATE,ILLPTOM,IMPLICITINT,NOINLINENAMESPACE,LIBEXT,LONGLONG, NONEWEX CP,O NOOLDDIGRAPH,OLDFRIEND,NOOLDMATH,NOOLDSTR,OLDTEMPACC,NOOLDTMPLALIGN,O LDTMPLS PEC, NOTEMPSASLOCALS,NOTEXTAFTERENDIF,GNU_LABELVALUE,GNU_COMPUTEDGOTO,TRAI LENUM,T YPED VARARGMACROS,NOVARIADICTEMPLATES,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99C OMPLEX, NOC9 NOGNU_COMPLEX,GNU_SUFFIXIJ) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Thursday, July 25, 2013 7:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem I think I see your problem. Try compiling with LANGLVL(LONGLONG). -- 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: Establishing and using Unix file system and USS under z/OS
On Sat, 27 Jul 2013 11:51:19 -0400, John Gilmore wrote: ... The problem here is, I think, one of concordance or coherence. Anyone who knows something of a statement-level language should be able to make plausible, almost invariably confirmed conjectures about how the rest of it goes; and mixing syntactic sugars defeats this. The syntax of ALL non-assignment PL/I and REXX statements, CICS commands, and some but not all IBM utilities is the same simple, well understood one. Lexical breakout is thus the same for any and all such statements, and token parsing can be table-driven. In a REXX environment it is better and much easier to stick to it. Of course there are two orthogonal scales of value that can be applied here: o Make the product comfortable to those accustomed to Perl. o Make the product comfortable to those accustomed to MVS. Yet I wonder. I don't know Perl. But I find sed regular expressions are hellishly hard to read, still I'm hard-put to imagine an alternative which would be significantly easier but not enormously tedious, in the tradition of COBOL (ADD A TO B GIVING C). An example as a challenge. This pointless sed regex replaces the third word of each line with wombat, indents the line 4 spaces, and leaves the number of spaces elsewhere in the line unchanged: sed 's/^\( *[^ ]\+ \+[^ ]\+ \+\)[^ ]\+/\1wombat/' (Ouch!) On z/OS, applied to a paragraph appearing above, it produces: The syntax wombat ALL non-assignment PL/I and REXX statements, CICS commands, and wombat but not all IBM utilities is the same simple, well understood one. wombat breakout is thus the same for any and all such statements, wombat token parsing can be table-driven. In a REXX environment it wombat better and much easier to stick to it. How might one imagine it sweetened with the syntactic sugar of MVS but still acceptably concise? Candidate schematic solutions welcome. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
On Sat, 27 Jul 2013 10:22:55 -0700, Lizette Koehler wrote: Charles, You are a vendor and may have found a problem with the C integer process. It would be of benefit to the community when you find something like this to report even if you do not get benefit directly. Instead you get an indirect benefit of helping the community and preventing someone else hours of searching and testing. If there was something wrong with one of your processes, would you want your customer to say - it is not worth it. Or would you want it reported so you can fix it. Just my 2 cents worth Thinking back on the recent SR Policy thread which I started, and to which you contributed, should the customer entertain the question, ...let me know what impact this issue has on your day to day business..., or should the customer expect a repair because it's The Right Thing To Do, and because it may spare a peer customer hours of searching and testing? Note that when Charles has a circumvention, he must honestly answer that the impact ... on [his] day to day business has been reduced to zero. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
I am thinking that even if Charles opens an issue, and then they come back and say - do this and that, he could close it at that point. And for this one, a lot of research and analysis has already gone into this problem. I think it might be worth just opening the case. All the documentation he has supplied would be available should someone else come across this issue and want to pursue. I have done this in the past. I had all the doc needed, but could not get a consistence recreation. So the issue was opened, doc supplied, then closed. Later on I learned someone else had the issue and was able to have a more consistent recreation. With my doc and theirs, the problem was easier to isolate. Lizette. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, July 27, 2013 12:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem On Sat, 27 Jul 2013 10:22:55 -0700, Lizette Koehler wrote: Charles, You are a vendor and may have found a problem with the C integer process. It would be of benefit to the community when you find something like this to report even if you do not get benefit directly. Instead you get an indirect benefit of helping the community and preventing someone else hours of searching and testing. If there was something wrong with one of your processes, would you want your customer to say - it is not worth it. Or would you want it reported so you can fix it. Just my 2 cents worth Thinking back on the recent SR Policy thread which I started, and to which you contributed, should the customer entertain the question, ...let me know what impact this issue has on your day to day business..., or should the customer expect a repair because it's The Right Thing To Do, and because it may spare a peer customer hours of searching and testing? Note that when Charles has a circumvention, he must honestly answer that the impact ... on [his] day to day business has been reduced to zero. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The Rubicon has been crossed: no more hardcopy IBM publications from the IBM Publications Center
If you don't really want to inventory and sell hard copies anymore raising their prices to very high levels is an elegant thing to do. It discourages most people from asking for them, and those few hard copies that continue to be sold will each be very profitable even on a print-on-demand basis. Then after a time, having weaned most people from using them, you can announce that hard copies will not longer be available on any terms. This is in fact a gentlemanly if devious way to proceed. There is a down side, but it is probably unimportant in the grand scheme of things. Hardcopy/print publication has a tradition of proofreading and literacy; the web does not; hence _does'nt_. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The Rubicon has been crossed: no more hardcopy IBM publications from the IBM Publications Center
John Gilmore wrote: If you don't really want to inventory and sell hard copies anymore raising their prices to very high levels is an elegant thing to do. It discourages most people from asking for them, and those few hard copies that continue to be sold will each be very profitable even on a print-on-demand basis. Then after a time, having weaned most people from using them, you can announce that hard copies will not longer be available on any terms. This is in fact a gentlemanly if devious way to proceed. There is a down side, but it is probably unimportant in the grand scheme of things. Hardcopy/print publication has a tradition of proofreading and literacy; the web does not; hence _does'nt_. And perhaps The definitive version of this publication is the hardcopy version. appearing behind the title page of the Principles of Operation. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
On Jul 27, 2013, at 2:08 PM, Paul Gilmartin wrote: Thinking back on the recent SR Policy thread which I started, and to which you contributed, should the customer entertain the question, ...let me know what impact this issue has on your day to day business..., or should the customer expect a repair because it's The Right Thing To Do, and because it may spare a peer customer hours of searching and testing? Note that when Charles has a circumvention, he must honestly answer that the impact ... on [his] day to day business has been reduced to zero. ---Deleted Paul: This is in my opinion a fuzzy error. Where the C issue is a classic bug(probably) your SR Policy is a gray area and it is harder to define a right/wrong answer (although probably you are right). Spelling such is a issue but not a real bug. It is a soft issue, in my opinion and a lot harder to get IBM interested. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: cobol
On 18 Jul 2013 05:09:46 -0700, in bit.listserv.ibm-main you wrote: First, and not meaning to come across as nasty, you need to learn IBM COBOL. This is a very basic question. You need to read about and understand the COBOL compile option TRUNC. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3PG31/2.4.53 quote *TRUNC(BIN)* The TRUNC(BIN) option applies to all COBOL language that processes USAGE BINARY data. When TRUNC(BIN) is in effect, all binary items (USAGE COMP, COMP-4, or BINARY) are handled as native hardware binary items, that is, as if they were each individually declared USAGE COMP-5: - BINARY receiving fields are truncated only at halfword, fullword, or doubleword boundaries. - BINARY sending fields are handled as halfwords, fullwords, or doublewords when the receiver is numeric; TRUNC(BIN) has no effect when the receiver is not numeric. - The full binary content of fields is significant. - DISPLAY will convert the entire content of binary fields with no truncation. *Recommendations:* TRUNC(BIN) is the recommended option for programs that use binary values set by other products. Other products, such as IMS, DB2, C/C++, FORTRAN, and PL/I, might place values in COBOL binary data items that do not conform to the PICTURE clause of the data items. You can use TRUNC(OPT) with CICS programs as long as your data conforms to the PICTUREclause for your BINARY data items. Wile all bets are off if we are talking about 5.1, TRUNC(OPT) will work fine if you understand the following rules. 1. The value clause will be limited by the picture thus PIC S9(4) can not have a value 10,000 even though a half word can handle it. 2. Any move to or from a USAGE BINARY field to either USAGE DISPLAY or USAGE PACKED-DECIMAL will be based on picture with this also holding true for mixed operands in an arithmetic operation. 3. MOVEs and Arithmetic operations involving only USAGE BINARY fields and no literal will be based on word size. This means that S9(4) BINARY fields can have plus or minus 16 kibi in them while S9(9) BINARY fields can have plus or minus 2 gibi in them. They can be converted to other USAGEs by first moving the S9(4) BINARY field to an S9(9) BINARY field and the S9(9) BINARY field to a S9(10) BINARY field. Clark Morris USAGE COMP-5 has the effect of applying TRUNC(BIN) behavior to individual data items. Therefore, you can avoid the performance overhead of using TRUNC(BIN) for every binary data item by specifying COMP-5 on only some of the binary data items, such as those data items that are passed to non-COBOL programs or other products and subsystems. The use of COMP-5 is not affected by the TRUNC suboption in effect. *Large* *literals* *in* *VALUE* *clauses:* When you use the compileroption TRUNC(BIN), numeric literals specified in VALUE clauses for binary data items (COMP, COMP-4, or BINARY) can generally contain a value of magnitude up to the capacity of the native binary representation (2, 4, or 8 bytes) rather than being limited to the value implied by the number of 9s in the PICTURE clause. /quote Or you need to change the definition from COMP to COMP-5 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3LR31/5.3.17.1 quote *COMPUTATIONAL-5**or* *COMP-5* *(native* *binary)* These data items are represented in storage as binary data. The data items can contain values up to the capacity of the native binary representation (2, 4 or 8 bytes), rather than being limited to the value implied by the number of nines in the picture for the item (as is the case for USAGE BINARY data). When numeric data is moved or stored into a COMP-5 item, truncation occurs at the binary field size rather than at the COBOL picture size limit. When a COMP-5 item is referenced, the full binary field size is used in the operation. The TRUNC(BIN) compiler option causes all binary data items (USAGE BINARY, COMP, COMP-4) to be handled as if they were declared USAGE COMP-5. /quote On Thu, Jul 18, 2013 at 6:52 AM, Ron Thomas ron5...@gmail.com wrote: Hello. We have a field defined S9(04) COMP , the value that is getting populated to this field from programs is defined as 9(04) so that works fine Now we want the data of length 5 bytes to be moved 28281, but less than 32781 which is maximum that s9(04) comp holds. Kindly let me know do we need to change the defintion of S9(04) COMP. Thanks, Ron T -- 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: Looking for help with an obscure C integer problem
Hello, another follower of IBM main just informed me offline, that he open a problem with IBM support and included my documentation. So there is no need to discuss this further. Thank you, kind regards Bernd Am 27.07.2013 21:11, schrieb Bernd Oppolzer: So I think we will not do anything about this, sorry. Sorry; I'm not involved in the decision processes there; if I were, I would act different. If some IBM people hanging around here read this: wouldn't it be possible that they take action based on my description of the error? I would appreciate it, and the C/C++ community here, too, I believe. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
On Sat, 27 Jul 2013 14:59:15 -0500, Ed Gould wrote: This is in my opinion a fuzzy error. Where the C issue is a classic bug(probably) your SR Policy is a gray area and it is harder to define a right/wrong answer (although probably you are right). Spelling such is a issue but not a real bug. It is a soft issue, in my opinion and a lot harder to get IBM interested. I certainly did not say that my SR Policy thread was motivated by the response to a report of a spelling error. In fact, it was a report of the misbehavior I discussed in the Buffering: stdout ... thread. I suppose you're free to deem it cosmetic or not as you choose. The good news is that IBM has reproduced the problem, even while prodding me for a statement of business impact (which I supplied, acknowledging that I was working on a PoC). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Establishing and using Unix file system and USS under z/OS
I think you should abandon the idea of trying to replicate perl syntax. Perl makes me want to hurl, it's user hostile. I just copied the API functions like match, search, replace and implemented a command for each one. I could and should have added functionality to process an entire stem array or file for efficiency. I would not argue about the merits or lack of them thereof of Perl, that's a matter of taste. I wanted to port the PHP implementation of PCRE interface to z/OS, which would translate into few well defined functions, similar to the suggestion above. But that proved to be too big of a task because the source code dependencies went too deep to the core PHP source and I did not want to port PHP to z/OS. If you want to develop such API from scratch (and I suggest you should look into PHP as a model), than by all means, it should work. If we have enough people in the project, than we may re-visit my PHP idea some time. ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
