Re: Looking for help with an obscure C integer problem
I can see nothing obviously wrong with your code. Because the function
is inlined there could be a subtle bug near where the function is
called. Can you reproduce the problem with a simple test driver?
FWIW, I implemented ffs64() like this.
static inline int ffs64( uint64_t word )
{
if ( word == 0 ) return 0;
int bit = 1;
if ( ( word 0x ) == 0 )
{
word = 32;
bit += 32;
}
if ( ( word 0x ) == 0 )
{
word = 16;
bit += 16;
}
if ( ( word 0xFF ) == 0 )
{
word = 8;
bit += 8;
}
if ( ( word 0xF ) == 0 )
{
word = 4;
bit += 4;
}
if ( ( word 0x3 ) == 0 )
{
word = 2;
bit += 2;
}
if ( ( word 0x1 ) == 0 )
{
bit += 1;
}
return bit;
}
On 22/07/2013 11:57 AM, Charles Mills wrote:
Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.
// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()
static const unsigned long long lswMask =
0x;
// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage
if ( valueToTest == 0 ) return 0;
unsigned int testWord;
testWord = valueToTest lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif
}
}
I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Sunday, July 21, 2013 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
I'm struggling to see what is wrong with testWord = valueToTest 32.
There are no side effects and the sequence point is at the end of the full
expression. Can anybody enlighten me?
Charles, is the code snippet you supplied the exact test cast that is
resulting in undefined behaviour? I cannot recreate the problem and I've
tried it on five different C++ compilers, including z/OS v1.13.
On 22/07/2013 2:33 AM, Charles Mills wrote:
Right. There are two things here:
1. Resolving the immediate problem (and understanding exactly why it
fails might be a good first step).
2. The quality of the code. You are right; it is poor code. I try to
write pretty good code. I take no pride in avoiding the use of
unnecessary parentheses. I confess, I (a.) failed to consider that
testWord = valueToTest 32 would not reliably operate as intended;
and (b.) I was completely satisfied when the function passed basic
unit tests and though no more of it. Lesson learned, hopefully. Not
certain exactly what the lesson is, but I will be more careful in the
future. I have learned to be cautious about integer type conversions,
but obviously not cautious enough. I guess the lesson is just like for
sequences of logical operators: use parentheses to force what you expect.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Harry Wahl
Sent: Sunday, July 21, 2013 11:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Charles,
Hi, here is my opinion (and this definitely falls under the category
of obscure C):
You are not considering the implications of sequence points in your
C/C++.
Sequence points should not be confused with operator precedence.
Operator precedence is determinate, sequence points are not.
I believe IBM XLC is at the C++11 level of C/C++. The C/C++ level is
relevant here because there are sometimes subtle, and sometimes not so
subtle, differences in how sequence points apply between various
levels of
C++.
While C++11
Re: ACS routine imbed/include function?
Thanks, I will have a look at it. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Saturday, July 20, 2013 17:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? Also here Additional Storage Administration Functions z/OS V1R11.0 DFSMSdfp Storage Administration z/OS V1R10.0-V1R11.0 SC26-7402-13 The following are additional storage administration functions: QSAVE and QRETRIEV ISMF commands The QSAVE and QRETRIEV ISMF commands let you save a query of frequently used parameters under ISMF. You can then retrieve the parameters by their query names. The QSAVE and QRETRIEV ISMF commands can be used while running the ISMF data set list or volume list options, interactively or in batch. Model Command Generator (ACBQFLM1 EXEC for saved ISMF lists and ACBQADM2 EXEC for DCOLLECT data) The Model Command Generator option creates a model command against each entry in a data set saved ISMF list, a saved ISMF volume list, or from DCOLLECT data. NaviQuest does the symbolic substitution. COPYFILT macro Using the COPYFILT macro you can create synchronized filter lists (FILTLISTs) that can be applied across all ACS routines. Create a FILTLIST member in your ACS routine source data set. Make all filter list updates there. Then call the COPYFILT macro from the command line to have the changes replicated across all of the ACS routines. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Saturday, July 20, 2013 8:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? I found the Naviquest Manual has some info on COPYFILT in it International Technical Support Organization NaviQuest Demonstration and Hands-On Usage Guide April 1996 SG24-4720 · Use COPYFILT for ACS filters Commonly the ACS changes that you make to include a new data subtype to be SMS-managed are to FILTLISTs. The DFSMS FIT process recommends that you have a single member that includes all FILTLISTs used by all ACS routines. You then make changes to the FILTLISTs in this single member. After all changes are made, you can move all FILTLISTs from the single member to each of the ACS routines. NaviQuest has a COPYFILT command to help you in the maintenance of FILTLISTs. The COPYFILT command automatically moves the FILTLISTs from a single PDS member to each of your ACS routines. COPYFILT also enforces change control documentation. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, July 15, 2013 6:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ACS routine imbed/include function? Vernooij, CP wrote: So I probably mixed some historical info in my memory. It would be nice to have, e.g. for dsname- of volser-filtlists used in more than one routine. However, there are not many enhancements in ACS routines the last decades, so I expect this will remain a wish. You've got my curiousity turned on and I searched my *ss off since your first post! It was indeed a long time I saw any announcement for ACS enhancements if at all. But then I wonder if you were thinking about 'COPYFILT macro: COPYLIB facility for FILTLISTs'. Granted that is for initial SMS setup. On the otherside, I wonder if you were refering to FILTERDD in DFDSS. There you can probably concatenate at your leisure... Hmmm, perhaps time for a Share thing? Think of it: one set of Include/exclude for DB2 folks, another for other dbas, etc. Groete / Greetings Elardus Engelbrecht -- 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay
Re: DCOLLECT QUESTION -RESULTS PUZZLING -
Hi Esmee, It is a little convoluted, but if you follow the code in the job deck, you can see it calls ACBQBAR7, check that code and you find that it calls ACBQADR3 and in there you find this:- DO WHILE(eof = 'no') dcolrec = rec.1 /* check to see if this a D record */ IF ((SUBSTR(dcolrec,5,1) = 'D') (SUBSTR(dcolrec,5,2) ¬= 'DC')) THEN DO /***/ /*initialize variables */ /***/ So it's only even going to select D types. Regards, Dave *** Dave, Thanks for the info. However I cannot find where I am selecting the D type records. Could you point it out? Thanks -- 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 22/07/2013 12:17 PM, Charles Mills wrote:
# 0 and NOINLINE TEST or 2 and INLINE NOTEST
# OPT(0) NOINLINE TEST GONUMBER
OPT(2) INLINE NOTEST NOGONUMBER COMPRESS
Are you concerned about the size of your load modules? I can understand
that in C++ code that uses STL templates but I would trade off bigger
load modules
for the better diagnostics that OFFSET GONUMBER give me.
# Turn on the LIST option - pseudo-assembler listing
# LIST
# Experiment for - does not seem to hurt anything
DLL(CBA)
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 8:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
Here is exact cut and paste with zero editing, complete with a typo in the
second comment. The code is unit tested on MS Visual Studio -- hence the two
#ifdef's.
// Find First Set
static inline int Ffs64(unsigned long long valueToTest)
{
// returns index of first set bit. Uses UNIX convention
where bit 1 is LSB of word for compatibilit with z/OS ffs()
static const unsigned long long lswMask =
0x;
// note Windows provides a _BitScanForward64() but I did it
this way to make it more z/OS-like for test purposes
// if we ever needed Windows efficiency, or if IBM provides
an ffs64(), then this should be re-written to take advantage
if ( valueToTest == 0 ) return 0;
unsigned int testWord;
testWord = valueToTest lswMask;
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif
}
}
I have strong -- but not utterly conclusive; you know what debugging a
complex program is like -- that for the value I had in the OP --
0x0034? -- the method returns 32, implying that the final ffs()
was called with testWord = 0.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Sunday, July 21, 2013 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
I'm struggling to see what is wrong with testWord = valueToTest 32.
There are no side effects and the sequence point is at the end of the full
expression. Can anybody enlighten me?
Charles, is the code snippet you supplied the exact test cast that is
resulting in undefined behaviour? I cannot recreate the problem and I've
tried it on five different C++ compilers, including z/OS v1.13.
--
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: [MVS-OE] Looking for help with an obscure C integer problem
Well I think it is a bug.
the following source:
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
printf( %08X %08X\n, b);
}
With OPT(0) it generated:
LARL r5,F'46'
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
ST r0,n(,r13,160)
LA r2,0
ST r2,n(,r13,164)
* uint32_t b = n 32;
Lr6,n(,r13,160)
Lr7,n(,r13,164)
SRDL r6,32
LR r0,r7
ST r0,b(,r13,168)
*
* printf( %08X %08X\n, b);
Lr15,=V(PRINTF)(,r3,102)
LR r4,r5
LA r1,#MX_TEMP1(,r13,152)
ST r4,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
BASR r14,r15
LR r15,r2
and printed: 0034*0034*
With OPT(3) it generated:
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15
* }
LA r15,0
and printed: 0034 *1000*
This is z/OS 1.13. I am not sure about the C compiler maintenance
level, but I can check.
regards, Tom
On 2013-07-22 12:00 AM, IBM-MAIN automatic digest system wrote:
Date: Sun, 21 Jul 2013 20:42:54 +0800 From: David Crayford
dcrayf...@gmail.com Subject: Re: [MVS-OE] Looking for help with an
obscure C integer problem On 21/07/2013 8:40 PM, Shmuel Metz (Seymour
J.) wrote:
In51eb3a4c.8010...@gmail.com, on 07/21/2013
at 09:33 AM, David Crayforddcrayf...@gmail.com said:
I don't like it because it's a hack to work around an puzzling
issue. I want to know why the optimizer is not generating the
correct code.
Why not report it as a bug?
We don't know if it is a bug without seeing Charles code asis.
--
G. Tom Russell
“Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear
“... and remember to leave good news alone.” — Gracie HeavyHand
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] Looking for help with an obscure C integer problem
The bug is in your code. Your only passing one argument to printf().
On 22/07/2013, at 8:38 PM, Tom Russell tom_russ...@sympatico.ca wrote:
Well I think it is a bug.
the following source:
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
printf( %08X %08X\n, b);
}
With OPT(0) it generated:
LARL r5,F'46'
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
ST r0,n(,r13,160)
LA r2,0
ST r2,n(,r13,164)
* uint32_t b = n 32;
Lr6,n(,r13,160)
Lr7,n(,r13,164)
SRDL r6,32
LR r0,r7
ST r0,b(,r13,168)
*
* printf( %08X %08X\n, b);
Lr15,=V(PRINTF)(,r3,102)
LR r4,r5
LA r1,#MX_TEMP1(,r13,152)
ST r4,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
BASR r14,r15
LR r15,r2
and printed: 0034*0034*
With OPT(3) it generated:
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15
* }
LA r15,0
and printed: 0034 *1000*
This is z/OS 1.13. I am not sure about the C compiler maintenance level, but
I can check.
regards, Tom
On 2013-07-22 12:00 AM, IBM-MAIN automatic digest system wrote:
Date: Sun, 21 Jul 2013 20:42:54 +0800 From: David Crayford
dcrayf...@gmail.com Subject: Re: [MVS-OE] Looking for help with an obscure
C integer problem On 21/07/2013 8:40 PM, Shmuel Metz (Seymour J.) wrote:
In51eb3a4c.8010...@gmail.com, on 07/21/2013
at 09:33 AM, David Crayforddcrayf...@gmail.com said:
I don't like it because it's a hack to work around an puzzling
issue. I want to know why the optimizer is not generating the
correct code.
Why not report it as a bug?
We don't know if it is a bug without seeing Charles code asis.
--
G. Tom Russell
“Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear
“... and remember to leave good news alone.” — Gracie HeavyHand
--
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
PSO Dataspace of JES2
Hi, I would like to retrive information reside in the PSO dataspace of JES2, I have done the following: USING HCCT,R5 MVC WSAJTOK,CCTJSTKN ALESERV ADD, add STOKEN to ALET X STOKEN=WSAJTOK, X ALET=WSAJESA, X CHKEAX=NO, X MF=(E,WSALL) So now I have the ALET of the JES address space. but the PSO datascape is related to the JES2 address space, I found that $PSOTOK have the ALET of the PSO dataspace but when I am doing the: LAM AR3,AR3,$PSOTOK SAC 512 GET INTO AR M L R3,CCTPAD START OF PAD C L R1,$HCCT GET THE HCCT B LAE R3,CCTPAD-HCCT-(PADPAD-PAD)(R1,0) MVC JTX_PROC_DD,PADNAME I got the S0E0-29 ABEND : An ALET specified an access list entry (ALE) that is not valid. I think that I should also do the ALESERV also for the PSO dataspace, but then I need to have the STOKN of it. Any one can help? Regards Milad -- 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
Are you coding in C or C++? static_cast is a C++ feature.
- Original Message -
From: Charles Mills charl...@mcn.org
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, July 20, 2013 5:36:01 PM
Subject: Re: Looking for help with an obscure C integer problem
Thanks. How would I solve this with a cast? I can force it to be wrong LOL
but can I force it to be right?
It seems to me like testWord = static_castunsigned long long(valueToTest
32) might not solve the problem because that cast seems to me to imply
that the expression inside the parentheses is *not* 64 bits.
Frankly, I am now leaning toward
union {
unsigned long long ll;
struct {unsigned int hi; unsigned int lo} s; } u;
u.ll = valueToTest;
and then using u.s.hi where I now use testWord.
I generally avoid unions because they can be a tad problematic. I think the
above actually violates the C standard which says you can't assign to member
x and then read member y (which pretty much negates the whole purpose of
unions other than, as Stroustrup suggests, saving space in memory).
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
As a general ROT I always use explicit casts.
On 21/07/2013, at 4:24 AM, Charles Mills charl...@mcn.org wrote:
Cross-posted to IBM-MAIN and MVS-OE.
I have the following code fragment in an inline function, compiled by
the IBM XLC compiler as C++:
unsigned long long valueToTest;
unsigned int testWord;
testWord = valueToTest 32;
It *appears* to me (from somewhat circumstantial evidence in a much
more complex big picture) when valueToTest has a value of
0x0034 then
- If I compile Opt(0),NoInline then testWord gets the value I expect,
0x0034; but
- If I compile Opt(2),Inline then testWord gets a value of 0.
Questions:
1. Does that seem plausible? That the code would work as intended
Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
guessing here) first cast valueToTest to an int of 0, then shift it
right 32, and then assign it to testWord?
2. What should I code to avoid that? I guess I could shift valueToTest
first (I don't need it again) and then in a separate statement assign
it to testWord. Is that the proper coding technique?
It's fairly involved to test the whole thing so I took the liberty of
imposing on you folks rather than just trying stuff. Thanks much.
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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] Looking for help with an obscure C integer problem
Since the evaluated expression is automatically converted to the type of the
left operand aspart of the assignment process, what purpose does the cast serve?
- Original Message -
From: David Crayford dcrayf...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, July 20, 2013 8:06:37 PM
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
Your casting a uint64_t to a uint64_t which is pointless. You should
cast to the return value (uint32_t).
I've just tried your example and I can't recreate the problem, with or
without casts and compiled with both OPT and NOOPT.
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
uint32_t c = static_castuint32_t(n 32);
printf( %08X %08X\n, b, c );
}
I can only assume that the optimizer is throwing away valueToTest for
some arcane reason. I've seen this happen with convoluted code with lots
of pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable
optimizations on that variable.
On 21/07/2013 8:27 AM, Charles Mills wrote:
Hmmm. Not following your logic but I may give it a try.
Charles
-Original Message-
From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
Crayford
Sent: Saturday, July 20, 2013 4:51 PM
To: mvs...@vm.marist.edu
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
If static_castuint32_t(valueToTest 32) doesn't fix it then the compiler
is broken. Note the cast to uint32_t not uint64_t.
On 21/07/2013, at 6:36 AM, Charles Mills charl...@mcn.org wrote:
Thanks. How would I solve this with a cast? I can force it to be wrong
LOL but can I force it to be right?
It seems to me like testWord = static_castunsigned long
long(valueToTest
32) might not solve the problem because that cast seems to me to
imply
that the expression inside the parentheses is *not* 64 bits.
Frankly, I am now leaning toward
union {
unsigned long long ll;
struct {unsigned int hi; unsigned int lo} s; } u;
u.ll = valueToTest;
and then using u.s.hi where I now use testWord.
I generally avoid unions because they can be a tad problematic. I
think the above actually violates the C standard which says you can't
assign to member x and then read member y (which pretty much negates
the whole purpose of unions other than, as Stroustrup suggests, saving
space in memory).
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
As a general ROT I always use explicit casts.
On 21/07/2013, at 4:24 AM, Charles Mills charl...@mcn.org wrote:
Cross-posted to IBM-MAIN and MVS-OE.
I have the following code fragment in an inline function, compiled by
the IBM XLC compiler as C++:
unsigned long long valueToTest;
unsigned int testWord;
testWord = valueToTest 32;
It *appears* to me (from somewhat circumstantial evidence in a much
more complex big picture) when valueToTest has a value of
0x0034 then
- If I compile Opt(0),NoInline then testWord gets the value I expect,
0x0034; but
- If I compile Opt(2),Inline then testWord gets a value of 0.
Questions:
1. Does that seem plausible? That the code would work as intended
Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
guessing here) first cast valueToTest to an int of 0, then shift it
right 32, and then assign it to testWord?
2. What should I code to avoid that? I guess I could shift
valueToTest first (I don't need it again) and then in a separate
statement assign it to testWord. Is that the proper coding technique?
--
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: [MVS-OE] Looking for help with an obscure C integer problem
I use them so that the reader of the code knows for certain sure that I did intend to change from one precision to another, with possible loss of information. Also, I like to compile with all messages enabled and still get no warnings. I do a fair amount of unnecessary coding to get an RC of 0, rather than 4. I'm a bit OCD about that. I compile open source software on Linux some times and just cringe at all the warnings that are produced. On Mon, Jul 22, 2013 at 8:23 AM, retired-mainfra...@q.com retired-mainfra...@q.com wrote: Since the evaluated expression is automatically converted to the type of the left operand aspart of the assignment process, what purpose does the cast serve? -- 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
Re: Looking for help with an obscure C integer problem
You remember incorrectly. The expr4essions of the right are evaluated accoriding to the normal rules. Only the final result is coerced into the type of the left operand. - Original Message - From: Bernd Oppolzer bernd.oppol...@t-online.de To: IBM-MAIN@LISTSERV.UA.EDU Sent: Sunday, July 21, 2013 11:44:11 AM Subject: Re: Looking for help with an obscure C integer problem BTW: I think I remember from an old book on C programming: if the target of an assignment is int, all operands on the right side are converted to int - if the target of an assignment is long, all operands on the right side are converted to long If I remember correctly, this would perfectly explain the behaviour you see (of course, it makes more sense for data types being shorter than the type of the assignment target, but if it's done as written above, you have it for longer types, too). Kind regards Bernd Am 21.07.2013 18:32, schrieb Bernd Oppolzer: Sorry for jumping late into this thread. Why not spend another variable of type long long to do the shift there? like unsigned long long valueToTest; unsigned int testWord; unsigned long long x; x = valueToTest 32; /* here */ testWord = (int) x; If now in the expression marked with /* here */ the compiler does not do the shift as a true 64 bit shift, there is no excuse and you should report this as a bug. The cast to int is done in the next statement. In the other case there may be some strange language rules that allow the long long variable to be casted to int before the shift - I don't know, but why lose time and think much about it? Kind regards Bernd Am 20.07.2013 22:24, schrieb Charles Mills: Cross-posted to IBM-MAIN and MVS-OE. I have the following code fragment in an inline function, compiled by the IBM XLC compiler as C++: unsigned long long valueToTest; unsigned int testWord; testWord = valueToTest 32; It *appears* to me (from somewhat circumstantial evidence in a much more complex big picture) when valueToTest has a value of 0x0034 then - If I compile Opt(0),NoInline then testWord gets the value I expect, 0x0034; but - If I compile Opt(2),Inline then testWord gets a value of 0. Questions: 1. Does that seem plausible? That the code would work as intended Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am guessing here) first cast valueToTest to an int of 0, then shift it right 32, and then assign it to testWord? 2. What should I code to avoid that? I guess I could shift valueToTest first (I don't need it again) and then in a separate statement assign it to testWord. Is that the proper coding technique? It's fairly involved to test the whole thing so I took the liberty of imposing on you folks rather than just trying stuff. Thanks much. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Encryption of data written to disks FICON channels
R.S. asked: BTW: What's wrong with whole disk encryption? Why field-level encryption is better? IMHO it addresses different needs. Arye Shemer wrote: First I 'll try to explain the reasoning behind my request. 1. Encryption of 'Data In Rest' is a requirement by local PCI regulation 2. Encryption of 'Data In Rest' is just one step (in probably of many) of data protection required by this regulation 3. Field encryption by DB2 is good solution but it does not covers files or reports (sysouts) which require another solution 4. Disk encryption is probaly the best and simple solution for encryption of 'Data In Rest' , but (there always are some buts) If you do not have disks which are encryption enable you have to buy them, it might be expensive So we thought that in order to comply with the regulation requirements we'll use (if exist) some device which encrypt/decrypt the data going/coming from the disks. R.S.: Right. But I suspected (and Arye has confirmed) that this was PCI or other regulation-driven. There are a couple of problems with whole-disk encryption for regulatory compliance: 1) Lack of Separation of Duties controls: since it's all-or-nothing, it's not really possible to say This user can see THIS data, but not THAT data using the encryption as a control. So now you have to add MORE controls. 2) Weaker security in terms of attack points. If you think of a stack, bottom to top, of hardware/OS(filesystem)/database/middleware/application, and think about encryption applied at each of those levels, each only protects the levels BELOW it. So if you encrypt at the application level, you're providing the most security: an attacker has to break the application to get at the real data. At the other extreme (hardware), all they need to break into is the machine. And so forth. Ron Hawkins noted: I don't have any problem with field, record or file level encryption, but there is a downside if you are doing remote copy over a network, as it encrypted data usually compresses very poorly. It's not a problem for everyone. Warning: Voltage-specific information follows. If you encrypt to binary, true. If you use Format-Preserving Encryption technology, the output looks like the input, and thus compresses just fine. AES FFX modehttp://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html (in final stages of NIST approval as an official mode of AES) provides this. Provably secure, vetted by third parties, etc. (hence NIST's willingness to adopt it as a standard). For z/OS, we have a number of native solutions, providing both Format-Preserving Encryption and Secure Stateless Tokenization technologies through the same API, with proper z/OS-style centralized control, ESM integration, etc. -- ...phsiii Phil Smith III p...@voltage.commailto:p...@voltage.com Voltage Security, Inc. www.voltage.comhttp://www.voltage.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PSO Dataspace of JES2
Ouch. There are quite a few issues with what you are trying to do : (1) Adding the STOKEN of a foreign ASID to your PASN-AL or DU-AL using CHKEAX=NO is violating z/OS system integrity. (2) The ALET that a foreign ASID uses to address data in a non-common dataspace will be completely different to the ALET value that your PASN will have to use for the same dataspace. (3) The JES PSO dataspace is owned by the JES2AUX ASID and not the JES2 address space. What are you attempting to achieve ? There is no real IBM-supported way of gathering private area data from an address space that you do not have a valid cross-memory bind - however the accepted safe way of doing it is via SRB/FRR rather than the AR-mode technique you have tried to use. I suggest that you take a look at the IEAMSCHD service and re-read the Auth ASM Services and Extended Addressability manuals. You might also want to search the IBM-Main archives as this has been discussed a few times over the years. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mil Hashoul Sent: 22 July 2013 14:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: PSO Dataspace of JES2 Hi, I would like to retrive information reside in the PSO dataspace of JES2, I have done the following: USING HCCT,R5 MVC WSAJTOK,CCTJSTKN ALESERV ADD, add STOKEN to ALET X STOKEN=WSAJTOK, X ALET=WSAJESA, X CHKEAX=NO, X MF=(E,WSALL) So now I have the ALET of the JES address space. but the PSO datascape is related to the JES2 address space, I found that $PSOTOK have the ALET of the PSO dataspace but when I am doing the: LAM AR3,AR3,$PSOTOK SAC 512 GET INTO AR M L R3,CCTPAD START OF PAD C L R1,$HCCT GET THE HCCT B LAE R3,CCTPAD-HCCT-(PADPAD-PAD)(R1,0) MVC JTX_PROC_DD,PADNAME I got the S0E0-29 ABEND : An ALET specified an access list entry (ALE) that is not valid. I think that I should also do the ALESERV also for the PSO dataspace, but then I need to have the STOKN of it. Any one can help? Regards Milad -- 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: [MVS-OE] Looking for help with an obscure C integer problem
No purpose at all. Merely clutching at straws trying to circumvent Charles
rather baffling problem. It's not uncommon to see casts like that but it is
unnecessary. Of course going the other way does require casts for conversion.
unsigned int anUInt = 0xc000;
long long aLongLong = (long long)anUInt 2; // 0x3 (correct)
C/C++ integral promotion rules can be a pitfall for the novice.
On 22/07/2013, at 9:23 PM, retired-mainfra...@q.com
retired-mainfra...@q.com wrote:
Since the evaluated expression is automatically converted to the type of the
left operand aspart of the assignment process, what purpose does the cast
serve?
- Original Message -
From: David Crayford dcrayf...@gmail.com
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Saturday, July 20, 2013 8:06:37 PM
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
Your casting a uint64_t to a uint64_t which is pointless. You should
cast to the return value (uint32_t).
I've just tried your example and I can't recreate the problem, with or
without casts and compiled with both OPT and NOOPT.
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
uint32_t c = static_castuint32_t(n 32);
printf( %08X %08X\n, b, c );
}
I can only assume that the optimizer is throwing away valueToTest for
some arcane reason. I've seen this happen with convoluted code with lots
of pointers to pointers etc.
Try qualifying valueToTest with volatile, which should disable
optimizations on that variable.
On 21/07/2013 8:27 AM, Charles Mills wrote:
Hmmm. Not following your logic but I may give it a try.
Charles
-Original Message-
From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David
Crayford
Sent: Saturday, July 20, 2013 4:51 PM
To: mvs...@vm.marist.edu
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
If static_castuint32_t(valueToTest 32) doesn't fix it then the compiler
is broken. Note the cast to uint32_t not uint64_t.
On 21/07/2013, at 6:36 AM, Charles Mills charl...@mcn.org wrote:
Thanks. How would I solve this with a cast? I can force it to be wrong
LOL but can I force it to be right?
It seems to me like testWord = static_castunsigned long
long(valueToTest
32) might not solve the problem because that cast seems to me to
imply
that the expression inside the parentheses is *not* 64 bits.
Frankly, I am now leaning toward
union {
unsigned long long ll;
struct {unsigned int hi; unsigned int lo} s; } u;
u.ll = valueToTest;
and then using u.s.hi where I now use testWord.
I generally avoid unions because they can be a tad problematic. I
think the above actually violates the C standard which says you can't
assign to member x and then read member y (which pretty much negates
the whole purpose of unions other than, as Stroustrup suggests, saving
space in memory).
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of David Crayford
Sent: Saturday, July 20, 2013 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Looking for help with an obscure C integer problem
As a general ROT I always use explicit casts.
On 21/07/2013, at 4:24 AM, Charles Mills charl...@mcn.org wrote:
Cross-posted to IBM-MAIN and MVS-OE.
I have the following code fragment in an inline function, compiled by
the IBM XLC compiler as C++:
unsigned long long valueToTest;
unsigned int testWord;
testWord = valueToTest 32;
It *appears* to me (from somewhat circumstantial evidence in a much
more complex big picture) when valueToTest has a value of
0x0034 then
- If I compile Opt(0),NoInline then testWord gets the value I expect,
0x0034; but
- If I compile Opt(2),Inline then testWord gets a value of 0.
Questions:
1. Does that seem plausible? That the code would work as intended
Opt(0),NoInline but that with Opt(2),Inline the compiler would (I am
guessing here) first cast valueToTest to an int of 0, then shift it
right 32, and then assign it to testWord?
2. What should I code to avoid that? I guess I could shift
valueToTest first (I don't need it again) and then in a separate
statement assign it to testWord. Is that the proper coding technique?
--
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
Re: Looking for help with an obscure C integer problem
C++ per OP. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired-mainfra...@q.com Sent: Monday, July 22, 2013 6:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem Are you coding in C or C++? static_cast is a C++ feature. -- 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
Update: - parentheses did not fix the problem: testWord = (valueToTest = 32); - splitting it into two instructions did not fix the problem: valueToTest = 32; testWord = valueToTest; - recompiling just the single module with Opt(0) rather than Opt(2) did fix the problem. Everything else 100% the same. It may well be the surrounding code that causes the problem but I don't have the time at this point to try a hundred different test cases. I think we definitely have a compiler bug here. I may try the union approach, or the pure C (no call to ffs()) code that David suggested. I might try un-inlining the function, although that is basically a part of the try a hundred different things approach. Also, thanks David, not sure why I pulled that GONUMBER out of there. I will give that some thought. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Monday, July 22, 2013 4:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem On 22/07/2013 12:17 PM, Charles Mills wrote: # 0 and NOINLINE TEST or 2 and INLINE NOTEST # OPT(0) NOINLINE TEST GONUMBER OPT(2) INLINE NOTEST NOGONUMBER COMPRESS Are you concerned about the size of your load modules? I can understand that in C++ code that uses STL templates but I would trade off bigger load modules for the better diagnostics that OFFSET GONUMBER give me. -- 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 Sun, 21 Jul 2013 17:03:55 -0400, John Gilmore wrote: begin extract It is at the compiler's and optimizer's discretion to decide the order of execution for code that the C++ standard does not specifically define. This includes overlapping execution. /end extract and this may be conceded. What is not in the compiler's and optimizer's discretion is to produce different final numerical or string results for different levels of optimization. Agreed, with an exception. Long ago, with a different language from a different vendor my program program checked when optimized. In debug mode it ran successfully and produced the result I intended. Reported to vendor who replied (correctly) that I had relied (inadvertently) on a construct described the reference as undefined, allowing the behavior to differ between different levels of optimization. I went away unsatisfied. The only permissible exception is that an error should be reported in debugging mode when the result is undefined and no error is reported in optimized mode. ( the problem occurred because in debugging mode the compiler generated the sequence: STH(truncating the value) LH (lest a breakpoint be set here) SLA In optimized mode, only the: SLA(with fixed-point overflow detected,) I consider it a shortcoming of aboriginal S/360 design that neither MH nor STH generates a fixed-point overflow error when appropriate.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [MVS-OE] Looking for help with an obscure C integer problem
With the constant 0x0034... as a literal in the code the compiler is able to
short-circuit the shift entirely.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Russell
Sent: Monday, July 22, 2013 5:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [MVS-OE] Looking for help with an obscure C integer problem
Well I think it is a bug.
the following source:
#include stdio.h
#include stdlib.h
#include stdint.h
#include string.h
int main( int argc, char **argv )
{
uint64_t n = 0x0034LLU;
uint32_t b = n 32;
printf( %08X %08X\n, b);
}
With OPT(0) it generated:
LARL r5,F'46'
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
ST r0,n(,r13,160)
LA r2,0
ST r2,n(,r13,164)
* uint32_t b = n 32;
Lr6,n(,r13,160)
Lr7,n(,r13,164)
SRDL r6,32
LR r0,r7
ST r0,b(,r13,168)
*
* printf( %08X %08X\n, b);
Lr15,=V(PRINTF)(,r3,102)
LR r4,r5
LA r1,#MX_TEMP1(,r13,152)
ST r4,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
BASR r14,r15
LR r15,r2
and printed: 0034*0034*
With OPT(3) it generated:
* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15* {
* uint64_t n = 0x0034LLU;
IILL r0,H'0'
IILH r0,H'52'
* uint32_t b = n 32;
*
* printf( %08X %08X\n, b);
LARL r1,F'26'
Lr15,=V(PRINTF)(,r3,74)
ST r1,#MX_TEMP1(,r13,152)
ST r0,#MX_TEMP1(,r13,156)
LA r1,#MX_TEMP1(,r13,152)
BASR r14,r15
* }
LA r15,0
and printed: 0034 *1000*
--
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
Before complaining somewhere about a compiler error, I would strongly recommend to take a look at the assembly listing. Not one look, but better: have another person take a second look. It once happened to me that by looking at the assembly listing I believed to see the evidence of a compiler error, when another person - maybe on this list - showed me that the IMO missing instruction appeared some thirty instructions later which made the code correct. And the error finally turned out to be a very simple error on my part. Kind regards Bernd Am 22.07.2013 16:54, schrieb Charles Mills: Update: - parentheses did not fix the problem: testWord = (valueToTest = 32); - splitting it into two instructions did not fix the problem: valueToTest = 32; testWord = valueToTest; - recompiling just the single module with Opt(0) rather than Opt(2) did fix the problem. Everything else 100% the same. It may well be the surrounding code that causes the problem but I don't have the time at this point to try a hundred different test cases. I think we definitely have a compiler bug here. I may try the union approach, or the pure C (no call to ffs()) code that David suggested. I might try un-inlining the function, although that is basically a part of the try a hundred different things approach. Also, thanks David, not sure why I pulled that GONUMBER out of there. I will give that some thought. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Ed, That is a very small subset these days. AFAIK - OBJ Decks from compilers, TSO XMIT datasets, TRSMAIN (though I think this is 6k) and a few others are still dependent on 3120 blksize. However, I would think allowing your users to specify BLKSIZE=0 would be a benefit. Unless you have one of the above, should be okay. Most Mainframe Storage ADMINs, could probably have ACS code that will override the SDB to the appropriate BLKSIZE based on the function. Or change control products (CHANGEMAN, ENDEVOR) could also override the specification of BLKSIZE=0. Just my 2 cents worth. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, July 22, 2013 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BLKSIZE=3120 A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? is z/OS still a mine field filled with subtle dependencies on BLKSIZE=3120? If such restrictions are known to still exist, can anyone help with any specifics? Thanks in advance... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- 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
The right operand in this case is the result of evaluating the expression. The quoted text is not meant to imply that operands are converted before the right hand expression is evaluated. If that were the case, then int x = 14.0/2.1; would evaluate to 7 which is demonstrably not the case. - Original Message - From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Sunday, July 21, 2013 1:26:54 PM Subject: Re: Looking for help with an obscure C integer problem You are 100% correct. You nailed it. Stroustrup p. 263: If both operands have arithmetic type, the right operand is converted to the type of the left preparatory to the assignment. That explains why it fails, but not why it works Opt(0). I am going to *guess* that Opt(0) it compiles as though I had coded testWord = static_castunsigned int(valueToTest 32) while with Opt(2) it compiles as though I had coded testWord = static_castunsigned int(valueToTest) 32; In your earlier post you suggested wasting another long long. Yes, that's an approach. Actually I am finished with valueToTest and can just do things in two steps without wasting a variable: valueToTest = 32; testWord = valueToTest; I am busy with other things perhaps until sometime this week but the first thing I am going to try is simply using parentheses to attempt to force the Opt(0) interpretation: testWord = (valueToTest 32); If that fails I will move on to more elaborate approaches. The two statement approach will either work or else it is a very clear bug and I will re-group. Will probably try the union approach at that point. Thanks! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Sunday, July 21, 2013 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for help with an obscure C integer problem BTW: I think I remember from an old book on C programming: if the target of an assignment is int, all operands on the right side are converted to int - if the target of an assignment is long, all operands on the right side are converted to long If I remember correctly, this would perfectly explain the behaviour you see (of course, it makes more sense for data types being shorter than the type of the assignment target, but if it's done as written above, you have it for longer types, too). Kind regards Bernd Am 21.07.2013 18:32, schrieb Bernd Oppolzer: Sorry for jumping late into this thread. Why not spend another variable of type long long to do the shift there? like unsigned long long valueToTest; unsigned int testWord; unsigned long long x; x = valueToTest 32; /* here */ testWord = (int) x; -- 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
BLKSIZE=3120
A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? is z/OS still a mine field filled with subtle dependencies on BLKSIZE=3120? If such restrictions are known to still exist, can anyone help with any specifics? Thanks in advance... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Last time I explored this issue, the problem went beyond 'help'. In many cases of 'product allocated' files, existing output blocksize was overridden by 3120 regardless of how it was set ahead of time. I really don't think that BLKSIZE=0 will cause a problem. You just may not get what you bargained for. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU, Date: 07/22/2013 09:28 AM Subject:Re: BLKSIZE=3120 Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU I took the giant leap several years ago and stopped using 3120 for TSO XMIT. I hard-code 27920. Not as wonderful as 0, but better than 3120. Several years now with no issues. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, July 22, 2013 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BLKSIZE=3120 A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On 7/22/2013 9:28 AM, Charles Mills wrote: I took the giant leap several years ago and stopped using 3120 for TSO XMIT. I hard-code 27920. Not as wonderful as 0, but better than 3120. Several years now with no issues. Good to know. I suppose for errors in help, rather than in the manual, I've got to go the PMR/APAR route as opposed to an RFC. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Gilbert has a zap on CBT file 183 to overlay 3120 with zero in the OUTPUT DCB of XMIT. It may have to be reworked. Regards, John K IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 07/22/2013 11:28:26 AM: From: Charles Mills charl...@mcn.org To: IBM-MAIN@listserv.ua.edu Date: 07/22/2013 11:28 AM Subject: Re: BLKSIZE=3120 Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu I took the giant leap several years ago and stopped using 3120 for TSO XMIT. I hard-code 27920. Not as wonderful as 0, but better than 3120. Several years now with no issues. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Monday, July 22, 2013 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BLKSIZE=3120 A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
W dniu 2013-07-22 18:08, Ed Jaffe pisze: A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? is z/OS still a mine field filled with subtle dependencies on BLKSIZE=3120? Well, IMHO it's not restriction, it is just allocation default. Good default in very old days, but not very bad today. Note, The difference between ~3k and optimal ~27k seem to be large, but the effects (performance, space used) give no big difference. BTW: DB2, LOGGER, MQ, and many many VSAM exploiters do use blocks 4kB. Is it far from 3kB? Of course you can try the above datasets with other (SDB) blocksize, and I bet nothing will break. Why didn't they change it? Well, it time to re-start the following subthreads: - TSO is moribound - if it isn't broken don't fix it (see latest implementation as IMBED for catalogs). Regards -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- 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
That is another case, because the right side operands are not ints. For ints, I saw references that all operands are promoted to ints, if they can be represented as an int (that is true for chars, shorts etc.). Don't know for sure about longs, for example; if long differs in size from int, and there are longs on the right side, will they be promoted (that is: truncated) to int, if there is an int on the left side, or will they be evaluated as longs? That's the key question IMHO, and there should be a reference in the C language description that makes it clear without doubt - but I did not yet find such a reference - had not much time to look for it. (IMO, it would be no good language design if such a core question is left to the compiler builder - I don't believe it is so). Kind regards Bernd Am 22.07.2013 18:27, schrieb retired-mainfra...@q.com: The right operand in this case is the result of evaluating the expression. The quoted text is not meant to imply that operands are converted before the right hand expression is evaluated. If that were the case, then int x = 14.0/2.1; would evaluate to 7 which is demonstrably not the case. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On 7/22/2013 12:08 PM, Ed Jaffe wrote: A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? is z/OS still a mine field filled with subtle dependencies on BLKSIZE=3120? If such restrictions are known to still exist, can anyone help with any specifics? Thanks in advance... Ed, If there are any restrictions, they should be APAR'ed. 3120, 6160, 6144, etc. is SO 20th century. It's amazing to me how many IBM and OEM products still ship these crappy blocksizes. It's why I submitted a SHARE requirement to have AMATERSE support SDB. Isn't it ironic that a utility designed to save DASD space uses a 6144 blocksize and actually wastes DASD? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Hmm. I *may* need to take back what I said. It looks like for XMIT I specify 27920 but it forces 3120. Would need to do more research and no time at the moment. I *know* I tell customers to allocate a file 27920, upload from the PC, and run RECEIVE against it, so I know that works -- or at least I am not getting customer complaints. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, July 22, 2013 10:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 W dniu 2013-07-22 18:08, Ed Jaffe pisze: A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? is z/OS still a mine field filled with subtle dependencies on BLKSIZE=3120? Well, IMHO it's not restriction, it is just allocation default. Good default in very old days, but not very bad today. Note, The difference between ~3k and optimal ~27k seem to be large, but the effects (performance, space used) give no big difference. BTW: DB2, LOGGER, MQ, and many many VSAM exploiters do use blocks 4kB. Is it far from 3kB? Of course you can try the above datasets with other (SDB) blocksize, and I bet nothing will break. Why didn't they change it? Well, it time to re-start the following subthreads: - TSO is moribound - if it isn't broken don't fix it (see latest implementation as IMBED for catalogs). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NFS automount help requested
Take this with a large bucketful of salt 'cause I haven't got my own automount set up yet but someone will likely stomp on it if it's blatantly incorrect. I think I recall (from feb) that you can't include directories in the name option ie. name cics/wsbind is not valid. I believe you have to set-up your map for /u/cics, such as ucics.map, then use name wsbind there. Give it a quick shot to confirm or shoot-down. ps. I'm also on the daily digest so I won't see list discussion/replies until tomorrow. It works for me. *grin* signature = 6 lines follows Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee How *do* you plan for something like that? Guardian Bob, Reboot For every action, there is an equal and opposite criticism. Systems Programming: Guilty, until proven innocent John Norgauer 2004 -Original Message- From: Alan Field [mailto:alan_c_fi...@bluecrossmn.com] Sent: July 19, 2013 15:11 Subject: NFS automount help requested [snip] But I really want this to be automounted on LPAR B. On LPAR B I have a /u/cics/wsbinds defined. I update my u.map file with name cics/wsbinds type NFS [snip] No matter what I try I cannot get this to automount. Given the MOUNT command works I suspect I have some confusion over the u.map definitions but hours of googling haven't resulted in anything useful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Partition a VTS 7720
Jerry, The partitioning available to the host systems is only by category numbers. You dont have to partition, but reasons to create 2 partitions in your case include: - tape management system - if not a single VMF shared between test/prod - TCDB - this must be shared to avoid conflicts of volume status - ICF catalogs containing tape data sets - if not online to both partitions you can get inconsistencies after tape management returns a volume to scratch, or a data set is created on 1 lpar but managed from another. That is why most people partition their system managed tape libraries including those which are virtual and have the dasd cache online to all system. Mike Wood -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Partition a VTS 7720
Radoslaw, #4) rmm use of REJECT ANYUSE had some limitations. You now have the option of using PRTITION statements in rmm parmlib for more effective partitioning. Use in conjunction with OPENRULE. Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
3120 * 15 = 46800 / 55996 = 83.58% of maximum. On Mon, Jul 22, 2013 at 12:41 PM, Charles Mills charl...@mcn.org wrote: Hmm. I *may* need to take back what I said. It looks like for XMIT I specify 27920 but it forces 3120. Would need to do more research and no time at the moment. I *know* I tell customers to allocate a file 27920, upload from the PC, and run RECEIVE against it, so I know that works -- or at least I am not getting customer complaints. Charles -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On 7/22/2013 10:41 AM, Charles Mills wrote: Hmm. I *may* need to take back what I said. It looks like for XMIT I specify 27920 but it forces 3120. Would need to do more research and no time at the moment. This finding is consistent with John Kalinich's post where he describes the availability of a ZAP on CBT File 183 to change XMIT's hard-coded BLKSIZE=3120 to BLKSIZE=0. The hard-coded BLKSIZE=3120 in XMIT's DCB will override (and replace) the customer BLKSIZE=27920 specification in the Format-1 disk label. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM getting out of the Ed business?
On Sat, 20 Jul 2013 23:26:36 -0500, Ed Gould edgould1...@comcast.net wrote: Big Blue cedes software and systems training biz to partners http://www.channelregister.co.uk/2013/07/16/ ibm_software_systems_training_channel/ *IF* this is true... is Z/os may not be far behind. Eh? What do you mean by z/OS may not be far behind.? The introduction of IBM Global Training Partners will provide clients with more options and opportunities to receive IBM-authorized training. Please watch the videos at http://www.ibm.com/training/us?lnk=ushpcs2 Alan Altmark Sr. Managing z/VM and Linux Consultant IBM Lab Services and Training -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
83.58% is hardly the end of the world IMHO. 27920 x 2 ~= 99.7% Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Monday, July 22, 2013 11:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 3120 * 15 = 46800 / 55996 = 83.58% of maximum. On Mon, Jul 22, 2013 at 12:41 PM, Charles Mills charl...@mcn.org wrote: Hmm. I *may* need to take back what I said. It looks like for XMIT I specify 27920 but it forces 3120. Would need to do more research and no time at the moment. I *know* I tell customers to allocate a file 27920, upload from the PC, and run RECEIVE against it, so I know that works -- or at least I am not getting customer complaints. Charles -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: BLKSIZE=3120
Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 The information in this e-mail, and any attachment therein is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although Sound Software Printing, Inc. attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, July 22, 2013 10:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 W dniu 2013-07-22 18:08, Ed Jaffe pisze: A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? is z/OS still a mine field filled with subtle dependencies on BLKSIZE=3120? Well, IMHO it's not restriction, it is just allocation default. Good default in very old days, but not very bad today. Note, The difference between ~3k and optimal ~27k seem to be large, but the effects (performance, space used) give no big difference. BTW: DB2, LOGGER, MQ, and many many VSAM exploiters do use blocks 4kB. Is it far from 3kB? Of course you can try the above datasets with other (SDB) blocksize, and I bet nothing will break. Why didn't they change it? Well, it time to re-start the following subthreads: - TSO is moribound - if it isn't broken don't fix it (see latest implementation as IMBED for catalogs). Regards -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita
Re: BLKSIZE=3120
If there are any restrictions, they should be APAR'ed. 3120, 6160, 6144, etc. is SO 20th century. It's amazing to me how many IBM and OEM products still ship these crappy blocksizes. It's why I submitted a SHARE requirement to have AMATERSE support SDB. Isn't it ironic that a utility designed to save DASD space uses a 6144 blocksize and actually wastes DASD? I have seen an AMATERSE requirement that was submitted for this and we did investigate the AMATERSE code. AMATERSE doesn't require the blocksize of the output data set for a pack operation to be 6144. If a blocksize has not already been determined before AMATERSE tries to OPEN the data set, then AMATERSE assigns a blocksize of 6144, which was a reasonable thing to do when AMATERSE was designed (before the existence of SDB). If you explicitly assign a blocksize when you allocate the data set, AMATERSE will use your blocksize. Changing AMATERSE to avoid assigning a blocksize of 6144, so that SDB can to its thing, appears to be a fairly easy code change, and I do anticipate that it will get done at some point in the future. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
When performing integer (not int) arithmetic with integer operands of rank lower than int, the operands will be promoted to either int or unsigned int. When adding two short or two char or a char and a short, both operands will be promoted to int before the addition and the result will be an int. When any operand is of rank greater or equal to int, all operands are promoted to the highest rank in the expression and the arithmetic is performed on that type. Operands of rank greater than int are not demoted to int. The expression in question involves shifting an unsigned long long and the result will be an unsigned long long. When the result is assigned to the left operand, it will be converted to the type of that operand. This is true regardless of the type of the left operand. - Original Message - From: Bernd Oppolzer bernd.oppol...@t-online.de To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, July 22, 2013 12:18:25 PM Subject: Re: Looking for help with an obscure C integer problem That is another case, because the right side operands are not ints. For ints, I saw references that all operands are promoted to ints, if they can be represented as an int (that is true for chars, shorts etc.). Don't know for sure about longs, for example; if long differs in size from int, and there are longs on the right side, will they be promoted (that is: truncated) to int, if there is an int on the left side, or will they be evaluated as longs? That's the key question IMHO, and there should be a reference in the C language description that makes it clear without doubt - but I did not yet find such a reference - had not much time to look for it. (IMO, it would be no good language design if such a core question is left to the compiler builder - I don't believe it is so). Kind regards Bernd Am 22.07.2013 18:27, schrieb retired-mainfra...@q.com: The right operand in this case is the result of evaluating the expression. The quoted text is not meant to imply that operands are converted before the right hand expression is evaluated. If that were the case, then int x = 14.0/2.1; would evaluate to 7 which is demonstrably not the case. -- 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: BLKSIZE=3120
A few months ago I assisted a customer who was having difficulty installing SimpList. The installation instructions specify the sequential data set the XMIT files are uploaded to MUST be allocated as BLKSIZE=3120, but the installer specified BLKSIZE=0. I don't remember exactly what problem this caused, but I do know that once the BLKSIZE was changed to 3120 the installation went smoothly. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Mon, 22 Jul 2013 15:32:37 -0400 From: d10j...@us.ibm.com Subject: Re: BLKSIZE=3120 To: IBM-MAIN@LISTSERV.UA.EDU If there are any restrictions, they should be APAR'ed. 3120, 6160, 6144, etc. is SO 20th century. It's amazing to me how many IBM and OEM products still ship these crappy blocksizes. It's why I submitted a SHARE requirement to have AMATERSE support SDB. Isn't it ironic that a utility designed to save DASD space uses a 6144 blocksize and actually wastes DASD? I have seen an AMATERSE requirement that was submitted for this and we did investigate the AMATERSE code. AMATERSE doesn't require the blocksize of the output data set for a pack operation to be 6144. If a blocksize has not already been determined before AMATERSE tries to OPEN the data set, then AMATERSE assigns a blocksize of 6144, which was a reasonable thing to do when AMATERSE was designed (before the existence of SDB). If you explicitly assign a blocksize when you allocate the data set, AMATERSE will use your blocksize. Changing AMATERSE to avoid assigning a blocksize of 6144, so that SDB can to its thing, appears to be a fairly easy code change, and I do anticipate that it will get done at some point in the future. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: BLKSIZE=3120
I, personally, as a z/OS system programmer tend to like SMP/E. IBM has made installation simple via ShopzSeries. I put in my order. I eventually get an email saying it is ready. I log on to get the download information that I need and run a single SMP/E job which downloads and sets it up (RECEIVE), ready to customize and install. CA is similar, but we haven't gone to using MSM yet (don't know why). But the other 2 sysprogs here tend to prefer to get XMIT type files, perhaps packaged in a zip file. One simply prefers XMIT format, but will work with the CA stuff, which is downloaded to a UNIX subdirectory when he is forced to (compressed PAX format). The second really despises anything other than simple XMIT. But, then, he really dislikes z/OS UNIX. On Mon, Jul 22, 2013 at 2:16 PM, Duffy Nightingale du...@soundsoftware.uswrote: Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 -- 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
Re: BLKSIZE=3120
Interesting. Thanks much! Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 The information in this e-mail, and any attachment therein is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although Sound Software Printing, Inc. attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, July 22, 2013 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 I, personally, as a z/OS system programmer tend to like SMP/E. IBM has made installation simple via ShopzSeries. I put in my order. I eventually get an email saying it is ready. I log on to get the download information that I need and run a single SMP/E job which downloads and sets it up (RECEIVE), ready to customize and install. CA is similar, but we haven't gone to using MSM yet (don't know why). But the other 2 sysprogs here tend to prefer to get XMIT type files, perhaps packaged in a zip file. One simply prefers XMIT format, but will work with the CA stuff, which is downloaded to a UNIX subdirectory when he is forced to (compressed PAX format). The second really despises anything other than simple XMIT. But, then, he really dislikes z/OS UNIX. On Mon, Jul 22, 2013 at 2:16 PM, Duffy Nightingale du...@soundsoftware.uswrote: Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 -- 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
Re: BLKSIZE=3120
FTP has some bizarre default, something like RECFM=U, BLKSIZE=511. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dave Salt Sent: Monday, July 22, 2013 12:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 A few months ago I assisted a customer who was having difficulty installing SimpList. The installation instructions specify the sequential data set the XMIT files are uploaded to MUST be allocated as BLKSIZE=3120, but the installer specified BLKSIZE=0. I don't remember exactly what problem this caused, but I do know that once the BLKSIZE was changed to 3120 the installation went smoothly. Dave Salt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
We prefer to have SMP/E installs for all our program products and specifically ask when researching new products to be selected. Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Duffy Nightingale Sent: Monday, July 22, 2013 12:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, Duffy Nightingale Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Small product with just a few libraries and fairly stand-alone is ok via XMIT. Especially if it is mostly maintained by replacement. Anything more complex is helped by SMP/E, but even with IBM (and CA) when done with SMP/E, there is still usually half or more of the install doing configurations and tailoring. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Duffy Nightingale Sent: Monday, July 22, 2013 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 Interesting. Thanks much! Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 The information in this e-mail, and any attachment therein is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although Sound Software Printing, Inc. attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, July 22, 2013 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 I, personally, as a z/OS system programmer tend to like SMP/E. IBM has made installation simple via ShopzSeries. I put in my order. I eventually get an email saying it is ready. I log on to get the download information that I need and run a single SMP/E job which downloads and sets it up (RECEIVE), ready to customize and install. CA is similar, but we haven't gone to using MSM yet (don't know why). But the other 2 sysprogs here tend to prefer to get XMIT type files, perhaps packaged in a zip file. One simply prefers XMIT format, but will work with the CA stuff, which is downloaded to a UNIX subdirectory when he is forced to (compressed PAX format). The second really despises anything other than simple XMIT. But, then, he really dislikes z/OS UNIX. On Mon, Jul 22, 2013 at 2:16 PM, Duffy Nightingale du...@soundsoftware.uswrote: Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 15:32:37 -0400, Jim Mulder wrote: AMATERSE assigns a blocksize of 6144, which was a reasonable thing to do when AMATERSE was designed (before the existence of SDB). If you explicitly assign a blocksize when you allocate the data set, AMATERSE will use your blocksize. ITYM TRSMAIN. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 12:16:00 -0700, Duffy Nightingale wrote: we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? IMO, well-implemented SMP/E packaging is preferable to non-SMP/E. However, non-SMP/E packaging is far preferable to poorly implemented SMP/E packaging. Getting it right is difficult and some vendors do a very poor job of it. IMO if a vendor doesn't do their SMP/E packaging correctly, it is better that they not bother. AFAIK, Innovation (FDR, etc.) still ships their products without SMP/E, and their installation is (IMO) one of the best. IIRC, Quickref is another that is not installed with SMP/E. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SR Policy
I just got a reply to an SR asking for more information about the problem, then adding the text: Please also let me know what impact this issue has on your day to day business so we can understand the situation better. I look forward to your reply and clarification. Thanks! Am I to infer that IBM no longer believes in repairing defects simply because it's the right thing to do? This rather blurs the line between an SR and a requirement. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Tom Marchant said: AFAIK, Innovation (FDR, etc.) still ships their products without SMP/E, and their installation is (IMO) one of the best. IIRC, Quickref is another that is not installed with SMP/E. SimpList can be added to that list as well. One reason is because many developers want to try SimpList by installing it in their own private libraries, and they don't have access to SMP/E. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Mon, 22 Jul 2013 15:35:49 -0500 From: m42tom-ibmm...@yahoo.com Subject: Re: BLKSIZE=3120 To: IBM-MAIN@LISTSERV.UA.EDU On Mon, 22 Jul 2013 12:16:00 -0700, Duffy Nightingale wrote: we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? IMO, well-implemented SMP/E packaging is preferable to non-SMP/E. However, non-SMP/E packaging is far preferable to poorly implemented SMP/E packaging. Getting it right is difficult and some vendors do a very poor job of it. IMO if a vendor doesn't do their SMP/E packaging correctly, it is better that they not bother. AFAIK, Innovation (FDR, etc.) still ships their products without SMP/E, and their installation is (IMO) one of the best. IIRC, Quickref is another that is not installed with SMP/E. -- Tom Marchant -- 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
SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Just taking this to a new thread Personally I prefer SMP/E installs. It provides the following Ease of installation Ease of verifying Maint Levels Ease of upgrades or phase outs. When I have NON SMP/E installs they tend to be just simple IEBCOPY from here to here. Then it is up to me to ensure a way to validate what is in production, what is in test, what maintenance levels are available. There have been some NON SMP/E install products that have done a good job with the three points. But I have to make sure it is documented, my team mates can find (or use) my documentation and that the process is bullet proof. If it cannot pass the Lizette Test for bullet-proofness, then I really do not want the product in my shop. At one of my previous lives, I was supporting an OEM product that was NON-SMP/E installed. It was a nightmare. They process was a bare bones TSO XMIT install. But I had no way to very if I had the current version of software or not. It took many iterations before I found a naming convention that would at least look like it could identify what version of the product I was running in sand box and everywhere else. I think if you have one or two LPARs it is not so bad. But when you are looking at 5 or more LPARs or more than one PLEX to maintain software on, the SMP/E is a big benefit. But, if you have a solid process that covers my concerns, I may not gripe too much over a non-SMP/E install. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Duffy Nightingale Sent: Monday, July 22, 2013 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 Interesting. Thanks much! Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 The information in this e-mail, and any attachment therein is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although Sound Software Printing, Inc. attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, July 22, 2013 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 I, personally, as a z/OS system programmer tend to like SMP/E. IBM has made installation simple via ShopzSeries. I put in my order. I eventually get an email saying it is ready. I log on to get the download information that I need and run a single SMP/E job which downloads and sets it up (RECEIVE), ready to customize and install. CA is similar, but we haven't gone to using MSM yet (don't know why). But the other 2 sysprogs here tend to prefer to get XMIT type files, perhaps packaged in a zip file. One simply prefers XMIT format, but will work with the CA stuff, which is downloaded to a UNIX subdirectory when he is forced to (compressed PAX format). The second really despises anything other than simple XMIT. But, then, he really dislikes z/OS UNIX. On Mon, Jul 22, 2013 at 2:16 PM, Duffy Nightingale du...@soundsoftware.uswrote: Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SR Policy
I have seen this question with most vendors. What is the impact to your environment. How critical is this to be fixed. I think it helps them to triage the problem and put it in the queue where it will get the correct attention. Is this a SHOP DOWN or a Minor inconvenience. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, July 22, 2013 1:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SR Policy I just got a reply to an SR asking for more information about the problem, then adding the text: Please also let me know what impact this issue has on your day to day business so we can understand the situation better. I look forward to your reply and clarification. Thanks! Am I to infer that IBM no longer believes in repairing defects simply because it's the right thing to do? This rather blurs the line between an SR and a requirement. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 16:41:12 -0400, Dave Salt wrote: SimpList can be added to that list as well. One reason is because many developers want to try SimpList by installing it in their own private libraries, and they don't have access to SMP/E. Shame on IBM for transmogrifying SMP/E into a product that presents an ineffable threat to system integrity, and for tolerating that situation, apparently indefinitely! Prior to that all programmers had access to SMP/E and could install products for trial in their own private libraries. On Mon, 22 Jul 2013 15:35:49 -0500, Tom Marchant wrote: IMO, well-implemented SMP/E packaging is preferable to non-SMP/E. However, non-SMP/E packaging is far preferable to poorly implemented SMP/E packaging. Getting it right is difficult and some vendors do a very poor job of it. IMO if a vendor doesn't do their SMP/E packaging correctly, it is better that they not bother. Where can I find some Rules of Thumb; an SMP/E style checker? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Ed: Some time ago (before the binder IIRC) the input into the link editor had a max block size of 3200 (if memory serves me). I think with the binder the restriction has been removed. Ed On Jul 22, 2013, at 11:28 AM, Charles Mills wrote: I took the giant leap several years ago and stopped using 3120 for TSO XMIT. I hard-code 27920. Not as wonderful as 0, but better than 3120. Several years now with no issues. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Ed Jaffe Sent: Monday, July 22, 2013 9:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: BLKSIZE=3120 A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: TSO/E RECEIVE command HELP LOGDATASET You may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. ... LOGDSNAMEYou may specify an alternate data set to be used for the logging of the transmitted data. This data set will be created if it does not exist. The data set should be created with a logical record length of 255, a record format of VB and a blocksize of 3120. /TSO/E RECEIVE command HELP Is this just outdated help? Or does this restriction still exist? -- 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: BLKSIZE=3120
On Mon, 22 Jul 2013 15:53:01 -0500, Paul Gilmartin wrote: On Mon, 22 Jul 2013 15:35:49 -0500, Tom Marchant wrote: IMO if a vendor doesn't do their SMP/E packaging correctly, it is better that they not bother. Where can I find some Rules of Thumb; an SMP/E style checker? I'm not aware of either. There is the Packaging Rules manual, but there is much that is not covered there. It is focused primarily on correct SYSMOD construction. Some other considerations for what I would call proper SMP/E packaging include: o Providing useful system holds as necessary o Using Fix Categories and SOURCEID to simplify maintenance o Providing frequently updated downloadable Enhanced Hold data for errors o Proper SUPs for error holds when a PTF resolves the error o Having a data base of APARs and PTFs that customers can search o Cross-product dependencies (IF...REQ) where applicable o It should NEVER be recommended that a customer use BYPASS(ID) or BYPASS(REQ) o Network delivery for products and service The products and maintenance should be thoroughly tested. In order for the testing to be thorough, many permutations need to be tested. Most PTFs should be able to be applied, restored and applied again without issues. This is not likely an exhaustive list. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Lizette: Well said. In the past 40+ years I have done all types of installs. SMPE in the end simplifies installation. I have frequently rejected a product just because that it is not installed via SMPE. I have seen everything from an IEBCOPY to quite complicated installation procedures. Yes it can be cumbersome to install via SMPE but every sysprog that I have worked with (except some well lets say amateur types) have generally liked SMPE(for IM) It is far easier to figure out levels of products with SMPE IMO. I have seen OEM's supply fixes with zaps (and use IDRDATA rather than SMPE) and when all is said and done the level of the product was almost always up in the air and made problem determination less straight forwardas IDRdata is not in a dump. Ed On Jul 22, 2013, at 3:46 PM, Lizette Koehler wrote: Just taking this to a new thread Personally I prefer SMP/E installs. It provides the following Ease of installation Ease of verifying Maint Levels Ease of upgrades or phase outs. When I have NON SMP/E installs they tend to be just simple IEBCOPY from here to here. Then it is up to me to ensure a way to validate what is in production, what is in test, what maintenance levels are available. There have been some NON SMP/E install products that have done a good job with the three points. But I have to make sure it is documented, my team mates can find (or use) my documentation and that the process is bullet proof. If it cannot pass the Lizette Test for bullet-proofness, then I really do not want the product in my shop. At one of my previous lives, I was supporting an OEM product that was NON-SMP/E installed. It was a nightmare. They process was a bare bones TSO XMIT install. But I had no way to very if I had the current version of software or not. It took many iterations before I found a naming convention that would at least look like it could identify what version of the product I was running in sand box and everywhere else. I think if you have one or two LPARs it is not so bad. But when you are looking at 5 or more LPARs or more than one PLEX to maintain software on, the SMP/E is a big benefit. But, if you have a solid process that covers my concerns, I may not gripe too much over a non-SMP/E install. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Duffy Nightingale Sent: Monday, July 22, 2013 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 Interesting. Thanks much! Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 The information in this e-mail, and any attachment therein is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although Sound Software Printing, Inc. attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of John McKown Sent: Monday, July 22, 2013 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 I, personally, as a z/OS system programmer tend to like SMP/E. IBM has made installation simple via ShopzSeries. I put in my order. I eventually get an email saying it is ready. I log on to get the download information that I need and run a single SMP/E job which downloads and sets it up (RECEIVE), ready to customize and install. CA is similar, but we haven't gone to using MSM yet (don't know why). But the other 2 sysprogs here tend to prefer to get XMIT type files, perhaps packaged in a zip file. One simply prefers XMIT format, but will work with the CA stuff, which is downloaded to a UNIX subdirectory when he is forced to (compressed PAX format). The second really despises anything other than simple XMIT. But, then, he really dislikes z/OS UNIX. On Mon, Jul 22, 2013 at 2:16 PM, Duffy Nightingale du...@soundsoftware.uswrote: Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? Thanks, -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
Folks, Does anybody have any guidelines for making a product SMP/E installable ??. Yes, I've been thru the manuals but what I don't find are recommendations and or 'gotchas' ... Any advice and or direction would be appreciated. Kind Regards. Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Monday, July 22, 2013 4:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120) Lizette: Well said. In the past 40+ years I have done all types of installs. SMPE in the end simplifies installation. I have frequently rejected a product just because that it is not installed via SMPE. I have seen everything from an IEBCOPY to quite complicated installation procedures. Yes it can be cumbersome to install via SMPE but every sysprog that I have worked with (except some well lets say amateur types) have generally liked SMPE(for IM) It is far easier to figure out levels of products with SMPE IMO. I have seen OEM's supply fixes with zaps (and use IDRDATA rather than SMPE) and when all is said and done the level of the product was almost always up in the air and made problem determination less straight forwardas IDRdata is not in a dump. Ed On Jul 22, 2013, at 3:46 PM, Lizette Koehler wrote: Just taking this to a new thread Personally I prefer SMP/E installs. It provides the following Ease of installation Ease of verifying Maint Levels Ease of upgrades or phase outs. When I have NON SMP/E installs they tend to be just simple IEBCOPY from here to here. Then it is up to me to ensure a way to validate what is in production, what is in test, what maintenance levels are available. There have been some NON SMP/E install products that have done a good job with the three points. But I have to make sure it is documented, my team mates can find (or use) my documentation and that the process is bullet proof. If it cannot pass the Lizette Test for bullet-proofness, then I really do not want the product in my shop. At one of my previous lives, I was supporting an OEM product that was NON-SMP/E installed. It was a nightmare. They process was a bare bones TSO XMIT install. But I had no way to very if I had the current version of software or not. It took many iterations before I found a naming convention that would at least look like it could identify what version of the product I was running in sand box and everywhere else. I think if you have one or two LPARs it is not so bad. But when you are looking at 5 or more LPARs or more than one PLEX to maintain software on, the SMP/E is a big benefit. But, if you have a solid process that covers my concerns, I may not gripe too much over a non-SMP/E install. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Duffy Nightingale Sent: Monday, July 22, 2013 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 Interesting. Thanks much! Duffy Nightingale Sound Software Printing, Inc. www.soundsoftware.us du...@soundsoftware.us Phone: 360.385.3456 Fax: 973.201.8921 The information in this e-mail, and any attachment therein is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although Sound Software Printing, Inc. attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of John McKown Sent: Monday, July 22, 2013 1:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 I, personally, as a z/OS system programmer tend to like SMP/E. IBM has made installation simple via ShopzSeries. I put in my order. I eventually get an email saying it is ready. I log on to get the download information that I need and run a single SMP/E job which downloads and sets it up (RECEIVE), ready to customize and install. CA is similar, but we haven't gone to using MSM yet (don't know why). But the other 2 sysprogs here tend to prefer to get XMIT type files, perhaps packaged in a zip file. One simply prefers XMIT format, but will work with the CA stuff, which is downloaded to a UNIX subdirectory when he is forced to (compressed PAX format). The second really despises anything other than simple XMIT. But, then, he really dislikes z/OS UNIX. On Mon, Jul 22, 2013 at 2:16 PM, Duffy Nightingale du...@soundsoftware.uswrote: Hello, I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something
SMP/E conventions (was: BLKSIZE=3120)
On Mon, 22 Jul 2013 16:51:51 -0500, Tom Marchant wrote: Where can I find some Rules of Thumb; an SMP/E style checker? I'm not aware of either. There is the Packaging Rules manual, but there is much that is not covered there. It is focused primarily on correct SYSMOD construction. Some other considerations for what I would call proper SMP/E packaging include: This briefly mentions tape construction, but makes no mention of packaging for network delivery. I submitted an RCF on this a couple years ago, which was received favorably, but no action is evident. I'm awaiting the z/OS 2.1 version with bated breath. o Providing useful system holds as necessary We try to. Feedback welcome. If any customer has attempted such feedback that hasn't reached me, try again. o Using Fix Categories and SOURCEID to simplify maintenance We don't. I believe Fix Categories is new; we haven't caught up. What's needed for SOURCEID? Would partitioning according to our monthly regression test cycle be of value? o Providing frequently updated downloadable Enhanced Hold data for errors We provide HOLDDATA; not Enhanced. But a customer has complained in this list that while timely it's poorly organized. We use IBM's HOLDSYS categories. o Proper SUPs for error holds when a PTF resolves the error We do. FSVO proper. Through 3 corporate ownerships we have never had a problem tracking system compatible with IBM's naming conventions, so our resolving PTFs SUP the PE SYSMOD ID, not an incident ID. This is legal according to SMP/E (although I have repeatedly needed to submit RCFs whenever an SMP/E manual inadvertently asserts otherwise.) I don't know how this is likely to work if a level-set PTF both SUPs a SYSMOD ID and uses that in an RMID operand of an element. But we've never generated such a level-set PTF. o Having a data base of APARs and PTFs that customers can search Don't know. o Cross-product dependencies (IF...REQ) where applicable We try. o It should NEVER be recommended that a customer use BYPASS(ID) or BYPASS(REQ) Our policy. Violated once by a rogue tech support person, with disastrous results. We have since reinforced the policy. o Network delivery for products and service We're a small appendage in a large corporation. Our downloadable service is simply SYSMODs with inline elements, zipped according to corporate standard. Nothing similar to ShopZ. For similar reasons our downloadable products are SMP/E RECEIVE FROMNETWORK file hierarchies, all zipped. If we tried to come closer to IBM's conventions, I imagine a network wonk's asking, FTP!? What do you want to use that old thing for? The products and maintenance should be thoroughly tested. In order for the testing to be thorough, many permutations need to be tested. Most PTFs should be able to be applied, restored and applied again without issues. I believe no vendor is capable of testing, e.g., all possible combinations of ten PTFs with no declared interactions (Cartesian product: 2**10). For major PTFs (SPEs), RESTORE is usually tested collaterally to iterative development. Minor PE PTFs are likely to be tested and go to field with no RESTORE tested. This has not been a problem. Except...: We deal with an ISV cross-compiler vendor who doesn't understand the mechanism of SMP/E RESTORE processing. I believe we've circumvented most of the problems they've introduced on this account. But I need to sit down and talk with them at length about the difficulties they're causing. This is not likely an exhaustive list. Any comments on post-APPLY link edit and script processing? We don't do this; it might simplify some processing at the cost of weaker control. Any comments on tailoring of data set names and attributes? The z/OS 2.1 symbol processing in SYSIN data sets will be a godsend for this, but only after all our customers have migrated to a z/OS level that provides such support. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SR Policy
Right, severity. Charles Composed on a mobile: please excuse my brevity Lizette Koehler stars...@mindspring.com wrote: I have seen this question with most vendors. What is the impact to your environment. How critical is this to be fixed. I think it helps them to triage the problem and put it in the queue where it will get the correct attention. Is this a SHOP DOWN or a Minor inconvenience. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, July 22, 2013 1:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SR Policy I just got a reply to an SR asking for more information about the problem, then adding the text: Please also let me know what impact this issue has on your day to day business so we can understand the situation better. I look forward to your reply and clarification. Thanks! Am I to infer that IBM no longer believes in repairing defects simply because it's the right thing to do? This rather blurs the line between an SR and a requirement. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SR Policy
On Mon, 22 Jul 2013 13:48:33 -0700, Lizette Koehler wrote: I have seen this question with most vendors. What is the impact to your environment. How critical is this to be fixed. I think it helps them to triage the problem and put it in the queue where it will get the correct attention. Is this a SHOP DOWN or a Minor inconvenience. There's a checkbox for that; I checked No and opened as SEV3. Tunnel vision. Imagine that Charles had reported his integer problem. But with a circumvention available it has no longer an impact on his day to day business. Does that justify IBM's leaving the pitfall for other customers to encounter, with anguish similar to Charles's? And for each customer, finding a circumvention becomes a one-time experience; no impact on day to day business. Ouch! Or is it IBM's responsibility to assess the potential distributed impact across the customer base? Defect-riddled software in the aggregate impacts day to day business even though the blame can not be laid on any single defect. -Original Message- From: Paul Gilmartin Sent: Monday, July 22, 2013 1:41 PM I just got a reply to an SR asking for more information about the problem, then adding the text: Please also let me know what impact this issue has on your day to day business so we can understand the situation better. I look forward to your reply and clarification. Thanks! Am I to infer that IBM no longer believes in repairing defects simply because it's the right thing to do? This rather blurs the line between an SR and a requirement. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 09:08:12 -0700, Ed Jaffe wrote: A customer (mildly) complained thatsome of our product allocations still use BLKSIZE=3120. I vaguely remember trying to change all of them to BLKSIZE=0 many years ago (probably before OS/390) and running into some issues with certain IBM utilities. Unfortunately, I can't remember the specifics. In starting to revisit this again, I noticed numerousoccurrences of '3120' in IBM help and documentation. For example, the TSO/E RECEIVE command HELP claims that the log data set must be BLKSIZE=3120: Is there any difference between explicitly specifying BLKSIZE=0 and simply omitting BLKSIZE? Except in COBOL? A War Story: Long prior to the advent of SDB, I had formed the habit of omitting BLKSIZE in my Rexx EXECs. The Rexx function library was smart: it chose good BLKSIZEs and/or I didn't much care about fractional deviations from absolute optimality. And, for all I knew (and didn't care) it adapted well to different device types. Suddenly I started getting Sx13 in old debugged EXECs. It seems that Rexx had deferred BLKSIZE selection to SDB, and SDB was doing a poorer job of selecting BLKSIZE than Rexx. In fact, it was (as then documented!) selecting BLKSIZE=80 for all subsystem data sets (JES and UNIX). RECFM=VBA,LRECL=137, BLKSIZE=80 worked poorly. But when I reported the problem, IBM had the fix at hand. Worked. But IBM warned me: o The repair was designed for JES, and was not certain to work for UNIX files. (Worked OK.) o The repair necessarily violated the _published_ specification of BLKSIZE=80, and if another customer complained, it might be necessary to revert it. o I was advised to stop deferring BLKSIZE and specify it explicitly in all my code. Considerably ironic that a consequence of SDB was that I was advised not to rely on it. (It's better now.) Is there any hope that COBOL will come to trust SDB when BLKSIZE is omitted, or would that necessarily entail a standards violation? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
At 16:51 -0500 on 07/22/2013, Tom Marchant wrote about Re: BLKSIZE=3120: Most PTFs should be able to be applied, restored and applied again without issues. This is an issue since the design of RESTORE is broken due to its poor handling of SUPS/PREs If I can Apply a SYSMOD I should be able to restore it without needing to also restore any SYSMODs it PREs. IOW: If it PREs SYSMOD1 which has Elements EL1 and EL2 and contains only a new EL1, then a restore should be able to just select EL1 from SYSMOD1 and not need to also restore SYSMOD1 (along with its PREs which then need to be Applied again). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFHSMDATASETSERIALIZATION | USERDATASETSERIALIZATION with DFHSM and z/OS 1.11
I run with USERDATASETSERIALIZATION and since I have many potentially multi volume PS datasets (Stripped/Extended in default dataclass), I really need to continue this. I also do EXPIREDDATASETS(SCRATCH). I also have disk datasets created with EXPDT=98nnn because I implemented TMM long ago. I have a process in place to detect and ALTER dsname NULLIFY RETENTION these and allow the MGMTCLAS (which is derived from EXPDT) to control expiration. Recently, the applications people shifted some processing around and found the window to create and then DFHSM expires before I get the EXPDT reset. This caused the next job to fail :( With USERDATASETSERIALIZATION, the DFHSM Integrity Age for Space Management is set to zero days. It appears a longer Integrity Age would delay this scratching of the dataset. I am contemplating using a PATCH to set this age to 1 or 2 and see if this keeps the dataset around long enough to reset. Does anyone have any experience or thoughts on such a DFHSM patch? Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Long prior to the advent of SDB, I had formed the habit of omitting BLKSIZE in my Rexx EXECs. The Rexx function library was smart: it chose good BLKSIZEs and/or I didn't much care about fractional deviations from absolute optimality. And, for all I knew (and didn't care) it adapted well to different device types. If I may quibble a bit with the reference to Long prior to the advent of SDB: REXX on MVS was introduced in TSO/E Version 2.1 for MVS/XA and MVS/ESA. I don't remember exactly when that was shipped, but I think it would have been in the 1987-1988 timeframe. I don't remember exactly when SDB was introduced, but I found an APAR OY19694 which was opened on January 5, 1989 for an SDB-related issue. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
You can still use native SMP/E in batch to retain control of your system
installs/maintenance: just do CBIPO instead of IBM's 'recommended'
installs (the distribution tapes should still be in the original format).
IBM had been trying to force us to use their SMP/E 'dialogs' since the
mid/late eighties; but we took no notice. Next IBM tried to force us to
use SystemPak, CustomPak, You-name-it-Pak etc. (as it was called then).
A bank asked me to install it for them in '99. So I did, I checked it -
and it was riddled with bugs (e.g. PROCs were written in lower case, and
why the heck did SystemPak need the master catalog password to install a
product anyway?). I raised a PMR with IBM about that and I got the
following answers.
- Level 1 said it was a 'wonderful product' and that all their customers
wanted it; so I replied that it was full of errors; escalate.
- Level 2 said that IBM had found that many of its customers could not
afford to hire sysprogs and that SystemPak allowed them to install
products without needing ditto; I replied again that it was full of
errors, that if IBM were so clever and their customers were so stupid
then why was it that IBM could not find e.g. the hlq of the current
PARMLIB instead of asking their customers to type it in a panel etc.;
escalate.
- Level 3 said (verbatim) I never said that I agreed with it; so I
replied Thanks, you can close the PMR.
I then told the bank that SystemPak was full of errors and suggested
rewriting it for them - such that it would be 100% compatible with IBM's
version (in case IBM eventually fixed it), but without the bugs and
hassle. The bank said OK. So I wrote and installed my own version of
SystemPak for them.
IBM then spent several weeks calling and asking me to explain how I had
fixed their SystemPak, so they could tell their developers in Canada -
but forgot to mention how much they would pay me for that (tut tut).
Later, at a different company in 2000, I found that IBM had still not
fixed their SystemPak bugs. It's a pity I cannot remember the PMR number
I raised in '99 (I left it behind, at the bank).
IBM is following Microsoft's lead, because 99% of its customers are
computer illiterate but also have 99% of the money. So why bother with
the 1% of us who know how to avoid wasting CPU cycles, VS and DASD space
- but who thereby prevent IBM from selling more hardware - when there
are 'oodles' of customers out there to whom IBM can sell 10 times more
hardware than they actually need, and who believe that to follow IBM's
'recommendations' is the correct and proper way to avoid making
mistakes? (It used to be called FUD.)
I would suggest that you stick with native SMP/E if you do not want IBM
to take it away from you ('out of support', as they say). You can create
your own CSIs by REPRO'ing the production ones (and then preferably into
a single VSAM KSDS as this is *not* recommended by IBM), then
UCLIN-changing them to point at your global/DLIB/TLIB zones and their
datasets (which you can also copy from the production ones) etc.
BTW TRSMAIN supports BLKSIZE=27648 for LRECL=1024 and IPCS supports
BLKSIZE=24960 for LRECL=4160, and you can ZAP any LMOD's hard-coded DCB
BLKSIZE to be whatever you want it to be - if it insists on overriding
yours.
Cheers, Chris Poncelet
Paul Gilmartin wrote:
On Mon, 22 Jul 2013 16:41:12 -0400, Dave Salt wrote:
SimpList can be added to that list as well. One reason is because many
developers want to try SimpList by installing it in their own private
libraries, and they don't have access to SMP/E.
Shame on IBM for transmogrifying SMP/E into a product that presents
an ineffable threat to system integrity, and for tolerating that
situation, apparently indefinitely! Prior to that all programmers
had access to SMP/E and could install products for trial in their own
private libraries.
On Mon, 22 Jul 2013 15:35:49 -0500, Tom Marchant wrote:
IMO, well-implemented SMP/E packaging is preferable to non-SMP/E.
However, non-SMP/E packaging is far preferable to poorly implemented
SMP/E packaging. Getting it right is difficult and some vendors do a very
poor job of it. IMO if a vendor doesn't do their SMP/E packaging correctly,
it is better that they not bother.
Where can I find some Rules of Thumb; an SMP/E style checker?
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
In 025801ce86f6$64021d20$2c065760$@mindspring.com, on 07/22/2013 at 09:13 AM, Lizette Koehler stars...@mindspring.com said: AFAIK - OBJ Decks from compilers, TSO XMIT datasets, TRSMAIN (though I think this is 6k) and a few others are still dependent on 3120 blksize. My recollection is that the 3120 limit for compilers, linkage editor and binder were lifted a long time ago. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
In 7455665327418361.wa.m42tomibmmainyahoo@listserv.ua.edu, on 07/22/2013 at 04:51 PM, Tom Marchant m42tom-ibmm...@yahoo.com said: This is not likely an exhaustive list. o Don't use RELFILE for ++ APAR or ++ PTF -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
In 00a401ce870f$e7dd43e0$b797cba0$@soundsoftware.us, on 07/22/2013 at 12:16 PM, Duffy Nightingale du...@soundsoftware.us said: I see another developer on here. And we send our product out using TSO XMIT. Which gives rise to a question. I saw some techie state that he would not install a product unless he could use SMP/E. Is this something us developers should explore or is it a big headache that is not worth it? At some shops, being unable to install a fix for a single bug is a major issue. The point of SMP/E is not to just use it as a packaging tool for the entire product but also to use it as a tracking tool for individual fixes. To keep your customers happy when they ask for SMP/E packaging, you have to not only use it but to use it properly. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SR Policy
In 326064299181.wa.paulgboulderaim@listserv.ua.edu, on 07/22/2013 at 03:41 PM, Paul Gilmartin paulgboul...@aim.com said: Am I to infer that IBM no longer believes in repairing defects simply because it's the right thing to do? I would infer that IBM wants to know whether it warrants an immediate fix or whether FIN is an acceptable resolution. FIN does not mean never, and I've even opened ETR's in which I suggested that FIN was appropriate. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Jim, Good memory. My memory is a bit different (not by much though). DFP 3.1 first offered SDB TSOe (I think) at 2.1 ++ many PTF's for Rexx . I recall having not to implement XA for REXX (not being fully ready and SWA (above) not being fully supported by vendors. In one case I had to change the (CA's) source code and the other had to wait for a ZAP from Compuware. I was not a happy camper and was calling the vendors daily for an update. Put back my installation by about a month. I had egg on my face at work. Ed On Jul 22, 2013, at 9:03 PM, Jim Mulder wrote: Long prior to the advent of SDB, I had formed the habit of omitting BLKSIZE in my Rexx EXECs. The Rexx function library was smart: it chose good BLKSIZEs and/or I didn't much care about fractional deviations from absolute optimality. And, for all I knew (and didn't care) it adapted well to different device types. If I may quibble a bit with the reference to Long prior to the advent of SDB: REXX on MVS was introduced in TSO/E Version 2.1 for MVS/XA and MVS/ESA. I don't remember exactly when that was shipped, but I think it would have been in the 1987-1988 timeframe. I don't remember exactly when SDB was introduced, but I found an APAR OY19694 which was opened on January 5, 1989 for an SDB- related issue. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: DCOLLECT QUESTION -RESULTS PUZZLING -
On 21/07/2013 7:15 PM, John McKown wrote:
Such as? I will grant that REXX is old. But so are PERL, awk, and many
other UNIX tools. Him, perhaps lua. But there is a port of lua to z/OS. A
person here was kind enough to send it to me.
If anybody is interested in Lua drop me a line. I've been having lots of
fun with it and have recently been getting my feet wet with co-routines.
Co-routines are analogous to generators
in Javascript and Python and are very powerful for implementing non
pre-emptive, collaborative multi-threading. The idea is to turn a
function call inside out. They really are neat for
creating very elegant patterns. I'm a big fan of unix pipes and
co-routines can implement sources, sinks and filters in a very concise
way. The following example is a little test driver I knocked up
to simulate processing CICS CMF records with different types of filters
for serializing to JSON, ZLIB compression etc.
io = require(io)
zlib = require(zlib)
json = require(cjson)
socket = require(socket)
-- ZLIB compression filter
function zip(prod)
return coroutine.create(function ()
local dstream = zlib.deflate(zlib.BEST_SPEED)
while true do
local status, value = coroutine.resume(prod)
if not status then break end
coroutine.yield(dstream(value, full))
end
end)
end
-- filter to serialize a lua table to a JSON string
function jsonify(prod)
return coroutine.create(function ()
while true do
local status, value = coroutine.resume(prod)
if not status or not value then break end
coroutine.yield(json.encode(value) .. \n)
end
end)
end
-- filter to translate EBCDIC to ASCII
function e2a(prod)
return coroutine.create(function ()
while true do
local status, value = coroutine.resume(prod)
if not status or not value then break end
coroutine.yield(os.e2a(value))
end
end)
end
-- file sink - defaults to QSAM but could take parameters
function file_sink(prod)
local o, msg = io.open(SMF.OUTPUT, wb, type=record, noseek)
if not o then
print(msg)
os.exit(8)
end
while true do
local status, rec = coroutine.resume(prod)
if not status or not rec then break end
print(rec)
o:write(rec)
end
end
-- socket sink to send stuff over the wire
function socket_sink(prod)
local host = 172.17.70.3
local port = 6870
local c = socket.connect(host, port)
while true do
local status, rec = coroutine.resume(prod)
if not status or not rec then break end
c:send(rec)
end
end
-- simulate reading an SMF file
function file_source()
return coroutine.create(function ()
for n = 1, 1500 do
local smfrec = {}
smfrec.type = 110 -- CMF record
smfrec.applid = CICSWARE
smfrec.sysid = MVS1
coroutine.yield(smfrec)
end
end)
end
-- main
file_sink(zip(jsonify(file_source(
file_sink(zip(file_source()))
file_sink(jsonify(file_source()))
socket_sink(e2a(jsonify(file_source(
socket_sink(zip(e2a(jsonify(file_source()
Lua is very fast. I've profiled it extensively using IBM Application
Performance Analyzer and the interpreter overhead is 10%. The majority
of the time is spent in fast C library code.
Oh course, I do the same. But I do it to save on z/OS MSUs.
On Jul 21, 2013 2:40 AM, Shane Ginnane ibm-m...@tpg.com.au wrote:
On Sat, 20 Jul 2013 22:48:00 -0700, Lizette Koehler wrote:
If you go to CBTTAPE.ORG and go for FILE206, it seems to have a REXX
parser
for DCOLLECT records
Some (not too many) years ago I lifted a cbt offering to mangle dcollect
records - needed some mods for what I wanted, but did the job admirably.
Not sure if this was it, but as always, the cbt has things you can use - or
use as templates at least.
Maybe If I was doing it today I'd flick the file to zLinux and use tools
more applicable to this century than Rexx.
Shane ...
--
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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On Mon, 22 Jul 2013 21:25:23 -0400, Robert A. Rosenberg wrote: This is an issue since the design of RESTORE is broken due to its poor handling of SUPS/PREs If I can Apply a SYSMOD I should be able to restore it without needing to also restore any SYSMODs it PREs. IOW: If it PREs SYSMOD1 which has Elements EL1 and EL2 and contains only a new EL1, then a restore should be able to just select EL1 from SYSMOD1 and not need to also restore SYSMOD1 (along with its PREs which then need to be Applied again). Several releases ago, at OS/390 V2R5.0 SMP/E, SMP/E introduced the Improved load module build processing, which for building _new_ load modules during _APPLY_ processing supported fetching ++MOD elements from the GLOBAL zone. Alas, it does not support such selection when updating a load module as in RESTORE, nor selecting other element types such as ++MAC from the GLOBAL zone. It's a pity that SMP/E did not follow through to provide such function as you (and I) want for greater flexibility of RESTORE. If that were done, ACCEPT would become a needless function. IBM has stated that the design objective of RESTORE is to reset objects to an ACCEPTed level; as such it performs its function admirably and needs no enhancement. You and I feel differently from IBM here. The corresponding VM facilities, VMFMERGE and VMSES/E have no requirement for a function analogous to ACCEPT. Accordingly, they provide the flexibility we'd like to see in SMP/E RESTORE. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
