Re: WLM managed workload
Ituriel, I agree that it is not WLM's goal to balance systems but to achieve goals. So if you have a 30% and 90% lpar, both running according to goal, WLM is happy. If one goal is not met, will shift workload by starting and stopping its initiators. However, this process stops far too rapidly when all systems are above 95% used, because WLM considers them both full and sees no use in more managing. It is this decision that I want to be more elaborated in/by WLM. It is perfectly possible to improve bad PIs in systems that are 98% and 100% used by shifting jobs b.m.o. starting and stopping initiators. I do this by hand and I see no reason why WLM can't do this too. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ITURIEL DO NASCIMENTO NETO Sent: Wednesday, July 24, 2013 17:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: RES: WLM managed workload Kees, The intent of JES2 and WLM is not to balance batch workload. WLM does not want that jobs, transactions be fast, WLM wants them happy, and for WLM, happy means PI less than 1. We have seen in the past a terrible work done by JES2 and WLM when spreading batch jobs in several images of a JESPLEX, where a Lpar was running at 90% while others were running at 30%. Despite Load discrepancy, all goals were been met, but it's ugly to see and hard to explain. Actually there is a redbook that explains in detail how they work together, and it is very illustrative (http://www.redbooks.ibm.com/redbooks/pdfs/sg246472.pdf). I think there is no easy way to do what you want, if there is. Our goal here was to spread batch workload in a way that all Lpars should be running with similar load, and to do so, we have developed a batch load scheduling that put things in order, and now we see no big differences among Lpars involved. Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto BANCO BRADESCO S.A. 4250 / DPCD Engenharia de Software Sistemas Operacionais Mainframes Tel: +55 11 3684-2177 R: 42177 3-1402 Fax: +55 11 3684-4427 Agora é BRA. BRA de Brasil. BRA de Bradesco. Patrocinador oficial dos Jogos Olímpicos e Paralímpicos Rio 2016. -Mensagem original- De: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Em nome de Vernooij, CP - SPLXM Enviada em: quarta-feira, 24 de julho de 2013 10:38 Para: IBM-MAIN@LISTSERV.UA.EDU Assunto: Re: WLM managed workload Allan, With WLM managing where work is initiated, I meant, that, when more capacity is needed, WLM starts WLM Managed Initiators where capacity is available and stops them on systems that are full. By means of this it has control over where jobs in WLM managed jobclasses are initiated and doint so it can route more work to one system and less work to another. In other words, it can help balance the load of the systems in the sysplex. My complaint/wish is, that it should do more to route work from full and overloaded systems to full but yet not overloaded systems. However, it considers systems over 95% utilized equally as full, as if they cannot be helped anymore and I think they can. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Wednesday, July 24, 2013 14:50 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM managed workload WLM considers all LPARs within the sysplex to be equal. WLM by itself, has no control over where the work is initiated. In conjunction with JES2 at the z/OS 2.4 level and higher, the ability was created to allow work to be started via workload managed initiators. Without going into the details, job queue time is now included as part of the WLM performance index when deciding whether to add work to the system. Also with WLM managed initiators, the current PI for the work on a given LPAR Is taken into consideration when deciding where to initiate the work (subject to other considerations(scheduling environment, system affinity,.) ). This can also be complicated by a multiple JESPLEX with a SYSPLEX. The short story on Workload Managed initiators is as follows: 1) JES2 and WLM initiators can be mixed at will. Each jobclass defined/used should be either JES or WLM managed, but not both. i.e. a given jobclass is either workload managed or jes managed. 2) A separate WLM service class should be defined for the WLM managed work to prevent misleading PI's based on the queue time component of the WLM PI calculation. There is a lot more to this, and I suggest reading the JES2 and WLM manuals extensively before proceeding. There are also several presentations from SHARE, that are quite helpful. HTH, snip WLM takes the load and performance of LPARs in consideration, by starting and stopping WLM Managed Initiators on systems that have capacity available or are overloaded. But it does this very coarse, putting a line at 95% utilization. When you have several LPARs that
Blame COBOL (manual)
I just found in COBOL manual a chapter about support for VSAM passwords. (See chapter Protecting VSAM files with a password in Programming Guide) Well, I can understand the PASSWORD clause is still syntax checked, but I was told that VSAM do dropped support for the password. Was it in the 90's? At DFSMS v1.5? (OS/390 2.7)? There are also some references to ISAM datasets, fortunately most of them contains information it's no longer supported. Is COBOL language for the future? BTW: Horror story: 10+ years ago I've got some IDC message, an error was occured. I took (R)TFM and read message explanation. One of the possibilities was you have problem with OS CVOL. Note, it was in late 90's, OS/390 v2. My doubts: Is my CVOL failing? How to check it? And what the hell is CVOL? I had never heard about it! It was hard way to learn there WAS such dodo bird like CVOL and like dodo bird it's no longer here. BTW2, quiz: do you still use HIS on the mainframe? Is it something new or it's as obsolete as CVOL? ;-) -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee 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 Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unsigned packed decimal
On Wed, 24 Jul 2013 08:00:07 -0500, John McKown john.archie.mck...@gmail.com wrote: 01 UNSIGNED-PACKED-TIMES-10. 05 UNSIGNED-PACKED PIC X(2). 05 FILLER PIC X VALUE IS X'0F'. There be dragons... 01 NORMAL-PACKED REDEFINES UNSIGNED-PACKED-TIMES-10 PIC S9(5) PACKED-DECIMAL. 01 NORMAL-UNPACKED PIC 9(4) USAGE DISPLAY. MOVE name-of-unsigned-packed-field TO UNSIGNED-PACKED OF UNSIGNED-PACKED-TIMES-10. DIVIDE NORMAL-PACKED BY 10 GIVING NORMAL-UNPACKED. This will work only the first time round. Next time the upper nibble of the FILLER will contain a sign nibble and your value will be incorrect... You have to re-initialise the UNSIGNED-PACKED-TIMES-10 with an INITIALISE or give the FILLER a proper name and MOVE ZERO to it. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unsigned packed decimal
Huh? How do you arrive at that conclusion? The example code moves data to the 2 bytes within the group called UNSIGNED-PAKED-TIME-10 but never moves anything to the byte defined as FILLER. The DIVIDE uses all 3 bytes as the numerator but the quotient is a completely separate field so nothing is overlaid by it. Which instruction are you thinking destroys the upper nibble of the FILLER byte? I just don't see it. C- Charles (Chuck) Hardee Senior Systems Engineer/Database Administration CCG Information Technology Thermo Fisher Scientific 300 Industry Drive Pittsburgh, PA 15275 Direct: 724-517-2633 FAX: 412-490-9230 chuck.har...@thermofisher.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jantje. Sent: Thursday, July 25, 2013 6:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Unsigned packed decimal On Wed, 24 Jul 2013 08:00:07 -0500, John McKown john.archie.mck...@gmail.com wrote: 01 UNSIGNED-PACKED-TIMES-10. 05 UNSIGNED-PACKED PIC X(2). 05 FILLER PIC X VALUE IS X'0F'. There be dragons... 01 NORMAL-PACKED REDEFINES UNSIGNED-PACKED-TIMES-10 PIC S9(5) PACKED-DECIMAL. 01 NORMAL-UNPACKED PIC 9(4) USAGE DISPLAY. MOVE name-of-unsigned-packed-field TO UNSIGNED-PACKED OF UNSIGNED-PACKED-TIMES-10. DIVIDE NORMAL-PACKED BY 10 GIVING NORMAL-UNPACKED. This will work only the first time round. Next time the upper nibble of the FILLER will contain a sign nibble and your value will be incorrect... You have to re-initialise the UNSIGNED-PACKED-TIMES-10 with an INITIALISE or give the FILLER a proper name and MOVE ZERO to it. Cheers, Jantje. -- 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: Blame the COBOL, how cliché
On Wed, 24 Jul 2013 16:34:50 -0400, Phil Smith III li...@akphs.com wrote: So the reason the payroll system is broken is because COBOL is �old�? No, the payroll system is broken because the documentation is lost, the code is corrupt and 7mio+ lines of code have not been updated in 20+ years... Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blame COBOL (manual)
R. Skorupka wrote: I just found in COBOL manual a chapter about support for VSAM passwords. As always, yes, it is still there since my glorious MVS/XA days when I started. Well, I can understand the PASSWORD clause is still syntax checked, but I was told that VSAM do dropped support for the password. Indeed. I see this remark too in DFSMS Using Data Sets: Recommendation: Do not use VSAM password protection. Instead, use RACF or an equivalent product. Why recommendation? I think it is something to do with 'user-security-verification routine' for VSAM, if you *still* choose to use it instead of RACF or ESM. Is COBOL language for the future? Perhaps not. ;-) I think this is backward compatibility to the absolute extreme... Your ancient COBOL full of Egypt hieroglyphs may or may not run on the latest super z toys. ;-D I really wish that for all products, the vendor (IBM for example) says something like this: We plan to drop feature X in release 5 while we introduce replacement feature Z in release 2 (so you can gradually move from X to Z and get PTFs if you get any nasty surprises while using X as a workaround.) I also really wish that those COBOL developers can write something like this: Old compiled modules with PASSWORD will still be running fine (backward compatibility blah blah blah), but all new compile attempts with PASSWORD should fail with RC 4 with some meaningless IGYxxx messages. Same with ISAM, etc. Ok, enough ranting -) 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
Re: Blame the COBOL, how cliché
When I was in the Army and stationed in Korea in the early 70 due to a payroll error I had to get advances. Then they started taking the advances out of my pay before they even fixed the problem making matters worst. COBOL is not at fault in this issue. It is incompetence. It is poor management, probably managers who shouldn't have been in data processing to begin with. How else would you loss all the documentation except for fire and water. COBOL, though fairly old, can be well written by a competent skilled programmers, having done that early on in my career. The excuse that some of the COBOL code was corrupted is stupid. Really, has anyone ever seen decay or rust in any code? Did it have bugs? No. Every bug I have ever seen has been actually some programmer's mistake. Gary Gary L. Shiminsky Senior zVM/zVSE Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-1509 Fax 603-271-1516 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system. -Original Message- From: Phil Smith III li...@akphs.com Reply-To: IBM List IBM-MAIN@LISTSERV.UA.EDU Date: Wednesday, July 24, 2013 4:34 PM To: IBM List IBM-MAIN@LISTSERV.UA.EDU Subject: Blame the COBOL, how cliché http://preview.reuters.com/2013/7/9/wounded-in-battle-stiffed-by-the-penta go n So the reason the payroll system is broken is because COBOL is ³old²? Sheesh. That¹s really weakŠ Oy, and they tried PeopleSoft as a replacementŠ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
If anyone is better at this than I am and wants to bother with more
analysis, here is the LIST output of compiling the below. (Note that it is
inline, so here is where it is invoked.)
*int index = Utility::Ffs64(key);
LG r1,#SPILL0(,r13,448)
SRAG r0,r1,32
ST r0,valueToTest%33=32(,r13,416)
ST r1,valueToTest%33=32(,r13,420)
+ LG r0,valueToTest%33=32(,r13,416)
+ LTGR r0,r0
+ LGR r14,r0
+ BNE @32L1392
LGHI r3,H'0'
B@32L1393
+@32L1392 DS 0H
Lr1,ffs_ptr(,r6,908)
+ LTR r14,r14
+ BE @32L1395
+ ST r0,#MX_TEMP32(,r13,196)
+ LM r15,r0,EPA_WSA(r1,8)
+ ST r0,_CEECAA_(,r12,500)
+ LA r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
LGFR r3,r15
B@32L1393
+@32L1395 DS 0H
+ LM r15,r0,EPA_WSA(r1,8)
+ LGHI r2,H'0'
+ ST r0,_CEECAA_(,r12,500)
+ ST r2,#MX_TEMP32(,r13,196)
+ LA r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
+ AHI r15,H'32'
LGFR r3,r15
@32L1393 DS 0H
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 11: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.
--
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
Need to see more of the code before the function was invoked. What's
happening with key, where is it loaded etc.
On 25/07/2013 7:27 PM, Charles Mills wrote:
If anyone is better at this than I am and wants to bother with more
analysis, here is the LIST output of compiling the below. (Note that it is
inline, so here is where it is invoked.)
*int index = Utility::Ffs64(key);
LG r1,#SPILL0(,r13,448)
SRAG r0,r1,32
ST r0,valueToTest%33=32(,r13,416)
ST r1,valueToTest%33=32(,r13,420)
+ LG r0,valueToTest%33=32(,r13,416)
+ LTGR r0,r0
+ LGR r14,r0
+ BNE @32L1392
LGHI r3,H'0'
B@32L1393
+@32L1392 DS 0H
Lr1,ffs_ptr(,r6,908)
+ LTR r14,r14
+ BE @32L1395
+ ST r0,#MX_TEMP32(,r13,196)
+ LM r15,r0,EPA_WSA(r1,8)
+ ST r0,_CEECAA_(,r12,500)
+ LA r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
LGFR r3,r15
B@32L1393
+@32L1395 DS 0H
+ LM r15,r0,EPA_WSA(r1,8)
+ LGHI r2,H'0'
+ ST r0,_CEECAA_(,r12,500)
+ ST r2,#MX_TEMP32(,r13,196)
+ LA r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
+ AHI r15,H'32'
LGFR r3,r15
@32L1393 DS 0H
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 11: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.
--
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 Wed, 2013-07-24 at 16:32 -0700, retired mainframer wrote: I don't think SMPE's APF attribute is the root of the problem. It's likely that SMPE still needs APF for e.g. ESTAE CANCEL=NO. -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Establishing and using Unix file system and USS under z/OS
That would be in the JCL manual. But there aren't any examples. And if you are not really UNIX literate, but just learning, it could be difficult to put together something useful. So I'll give an example, using IEBGENER. This will copy the READ macro from SYS1.MACLIB into a UNIX file in your home directory. //STEP1 EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* OR WHATEVER //SYSIN DD DUMMY //SYSUT1 DD DISP=SHR,DSN=SYS1.MACLIB(READ), //SYSUT1 DD PATH='/u/myusername/READ.macro', // PATHOPTS=(OWRONLY,OTRUNC,OCREAT), // PATHMODE=(SIRUSR,SIWUSR), // FILEDATA=TEXT, // RECFM=FB,LRECL=80,BLKSIZE=0 Hopefully, the PATH is self explanatory. PATHOPTS contains the UNIX open() options. OWRONLY - only writing, no reading; OTRUNC - if file exists, truncate to 0 bytes. OCREAT - if the file doesn't exist, create it. One which I omitted is OEXCL. This say to fail the job with a JCL error if the file already exists. This prevents accidental overwriting. If you omit OTRUNC, you would mod on to the end of the existing data. PATHMODE sets the UNIX access bits. There are three sets of three bits. The sets are for: (1) USER - the RACF owner of the file; (2) GROUP - the RACF group of the owner of the file; (3) OTHER - everybody else. The three bits are for Read, Write, and eXecute. SIRUSR is for read for user. SIWUSR is write for user. FILEDATA=TEXT tells the access method to insert an NEL (end of logical line) character at the end of each logical record written. This is standard for text files. By UNIX convention, text files do _NOT_ contain arbitrary values. They only contain printable characters. Some control characters are considered printable. Such as tab, NEL, and a few others (I don't have a complete list). In addition to TEXT, there are BINARY and RECORD. BINARY means just that. But there are no record boundry indications. So unless you know what you're doing, it may be impossible to process the resulting file. RECORD says that the data is BINARY, but each logical record in the file is preceded by a 4 byte binary integer (PIC S9(8) BINARY) which contains the number of following bytes which are the next logical record. This is similar to a VB file, except that (1) the entire 4 bytes are valid data, not LLBB; (2) the length is only the length of the data portion, and does not include the 4 bytes themselves. For UNIX files, you really should specify the RECFM=, LRECL=, and BLKSIZE= because a UNIX file does not contain any meta data (VTOC entry) which has this information. Well, you might get away without specifying it, depending on the application. On Wed, Jul 24, 2013 at 10:32 PM, Ze'ev Atlas zatl...@yahoo.com wrote: OK Assuming I have OMVS available to me and my hoe is: /u/myusername and assume that I used oedit to create a simple text file How would I access this file from, let's say, IEBGENER JCL Thanks ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
In 51ee77c7.5070...@bremultibank.com.pl, on 07/23/2013 at 02:32 PM, R.S. r.skoru...@bremultibank.com.pl said: 11. The idea of SMP/E is to have one CSI and all the products, components in that. Nonsense. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
In 4589494201288586.wa.dlikensinfosecinc@listserv.ua.edu, on 07/23/2013 at 06:41 AM, Donald Likens dlik...@infosecinc.com said: I have been working with SMP/E since before there was an E (SMP) (over 40 years) and I believe shops that limit themselves to SMP/E installed products are simply causing themselves extra work. I might agree for a single CSECT product, but certainly not for a product with dozens of components. I am a consultant and a software developer. Recently had two installs. One from IBM using SMP/E and another not using SMP/E. Both products were of similar size and complexity. The installation for the none SMP/E installation took under a day. The installation for the SMP/E installed product took about a week and cost my client much more money (consulting fees). The Devil is in the details. Where did the time go? Were the two cases really similar, or just the product sizes. If a shop required an SMP/E maintained product, I guess I would create a CSI etc. but I would download it like a serverpac. Does that mean that all of your service would be in levelsets? You might lose some potential customers if so. -- 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: Blame COBOL (manual)
On Thu, 2013-07-25 at 06:13 -0500, Elardus Engelbrecht wrote: Old compiled modules with PASSWORD will still be running fine (backward compatibility blah blah blah), but all new compile attempts with PASSWORD should fail with RC 4 with some meaningless IGYxxx messages. I'm sure that you meant ... with some *self-documenting* IGYxxx messages. (Dave pokes the wasp nest and runs.) -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Establishing and using Unix file system and USS under z/OS
Very true. Makes me wish that the JCL converter, which is what I _think_ reads the JCL and creates the internal text, would be enhanced to basically act as if everything in a JCL statement which is not enclosed in apostrophes was in UPPER case. I think this is what HLASM does to support lower case input. On Thu, Jul 25, 2013 at 7:50 AM, Steve Comstock st...@trainersfriend.comwrote: On 7/25/2013 6:43 AM, John McKown wrote: That would be in the JCL manual. But there aren't any examples. And if you are not really UNIX literate, but just learning, it could be difficult to put together something useful. So I'll give an example, using IEBGENER. This will copy the READ macro from SYS1.MACLIB into a UNIX file in your home directory. //STEP1 EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* OR WHATEVER //SYSIN DD DUMMY //SYSUT1 DD DISP=SHR,DSN=SYS1.MACLIB(READ)**, //SYSUT1 DD PATH='/u/myusername/READ.**macro', // PATHOPTS=(OWRONLY,OTRUNC,**OCREAT), // PATHMODE=(SIRUSR,SIWUSR), // FILEDATA=TEXT, // RECFM=FB,LRECL=80,BLKSIZE=0 Hopefully, the PATH is self explanatory. PATHOPTS contains the UNIX open() options. OWRONLY - only writing, no reading; OTRUNC - if file exists, truncate to 0 bytes. OCREAT - if the file doesn't exist, create it. One which I omitted is OEXCL. This say to fail the job with a JCL error if the file already exists. This prevents accidental overwriting. If you omit OTRUNC, you would mod on to the end of the existing data. PATHMODE sets the UNIX access bits. There are three sets of three bits. The sets are for: (1) USER - the RACF owner of the file; (2) GROUP - the RACF group of the owner of the file; (3) OTHER - everybody else. The three bits are for Read, Write, and eXecute. SIRUSR is for read for user. SIWUSR is write for user. FILEDATA=TEXT tells the access method to insert an NEL (end of logical line) character at the end of each logical record written. This is standard for text files. By UNIX convention, text files do _NOT_ contain arbitrary values. They only contain printable characters. Some control characters are considered printable. Such as tab, NEL, and a few others (I don't have a complete list). In addition to TEXT, there are BINARY and RECORD. BINARY means just that. But there are no record boundry indications. So unless you know what you're doing, it may be impossible to process the resulting file. RECORD says that the data is BINARY, but each logical record in the file is preceded by a 4 byte binary integer (PIC S9(8) BINARY) which contains the number of following bytes which are the next logical record. This is similar to a VB file, except that (1) the entire 4 bytes are valid data, not LLBB; (2) the length is only the length of the data portion, and does not include the 4 bytes themselves. For UNIX files, you really should specify the RECFM=, LRECL=, and BLKSIZE= because a UNIX file does not contain any meta data (VTOC entry) which has this information. Well, you might get away without specifying it, depending on the application. On Wed, Jul 24, 2013 at 10:32 PM, Ze'ev Atlas zatl...@yahoo.com wrote: OK Assuming I have OMVS available to me and my hoe is: /u/myusername and assume that I used oedit to create a simple text file How would I access this file from, let's say, IEBGENER JCL Thanks ZA Nicely done, John. I would only add that you need be sure the ISPF editor has the CAPS profile value set to OFF before you key in the JCL: UNIX is case sensitive and the PATH value will almost certainly contain some lowercase letters, as John's example shows. If you don't issue CAPS OFF from the command line of the editor, the editor will, by default, uppercase all your data when you press Enter. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/**ROI/roi.htmlhttp://www.trainersfriend.com/ROI/roi.html --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
In fbecf4fe-4c6b-4d33-8e44-215adefea...@comcast.net, on 07/23/2013 at 03:14 PM, Ed Gould edgould1...@comcast.net said: IF the consultant uses SMPE to install the product (and he/she doesn't do anything off the books) any decent sysprog can come in and figure out what he/she did in with a minimum of effort. I've sometimes had to spend time figuring out what the correct CSI is. SMP/E can be very nice, but their is still a role for documentation. -- 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
ECTG usage
I'm trying to benchmark cputime (under CICS) with pieces of code I'm changing, ECTG before and ECTG after. I'm zeroing out operand 1 before the ECTG thus I get a negative value in GPR0(because ETCG subtracts the operand 1 with the timer value) after I'm doing a LCR of GPR0 to get the positive timer value. If the cputimer went negative during the test (timer interrupt), the second ECTG is higher than the 1st one and since I don't know the refeed value of the CPUTIMER, I can't tell how much cputime was spend. I know I could use CICS internal values or statistics) but since they made ECTG as non-privilege I figured I'd give it a try. So... I'm missing something in the concept (the refeed value and how many times the interrupt occured ?) Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a reverse bits hardware instruction?
Here's a single DC instruction I've posted May 2003 [search for what's your
most difficult assembler concept]
BYTE_FLIP DS 0CL256
TDC 256AL1*-T)/001)-((*-T)/002)*2)*X'80'
(((*-T)/002)-((*-T)/004)*2)*X'40'
(((*-T)/004)-((*-T)/008)*2)*X'20'
(((*-T)/008)-((*-T)/016)*2)*X'10'
(((*-T)/016)-((*-T)/032)*2)*X'08'
(((*-T)/032)-((*-T)/064)*2)*X'04'
(((*-T)/064)-((*-T)/128)*2)*X'02'
(((*-T)/128)-((*-T)/256)*2)*X'01')
HTH,
-Victor-
---
The macro at the end of my reply will generate a reverse translate table. I
tested it enough to see that it looked right but it has nothing to do with
my original point. I've found this discussion interesting and it has given
me reason to play with something other than the complex process I'm working
on now. My original point, as was taken by Charles, was that I prefer
automatic processes to generate anything but the simplest translate tables.
I prefer to do it in a program and copy it from a dump into a program
because the table is static. I don't need to generate it every time I
assemble.
In regards to TROO, the original problem was stated as translating a 64 bit
register. A STG, TR for 8 bytes, followed by a LRVG will more than suffice.
Though, I find your argument about the use of a TRTRE to simulate a FROGR
interesting. It brings the whole bit reversal into perspective. I'm not a
big fan of translate instructions (I use them often enough), particularly
those that require facilities and facility enhancements, unless you're
translating long strings and are willing to test the facility bits. I'm
sure that the translation and parsing facilities exist on most customer's
boxes by now but I emphasize most. When I awakened this morning, I wrote
an algorithm to do a load reverse bytes and bits using FLOGR to drive the
process. I'm going to give the idea of a FROGR simulation more thought and
continue this exercise later.
MACRO
LABEL REVTABLE ,
* Construct reverse bits translate table
LCLA I,J,K,L,M,N,O
LCLC X
LABEL DS 0DLIKE EM DOUBLE WORD ALIGNED
I SETA 0 STARTING VALUE
.TABLOOP ANOP LOOP UNTIL TABLE IS DONE
K SETA 1 NEED SIXTEEN ENTRIES PER LINE
X SETC 'AL1('
AGO.X16LP
.X16NXT ANOP
X SETC 'X'.'J'.','
.X16LP ANOP 16 ENTRY LOOP
J SETA 0 STARTING RESULT
L SETA 1 STARTING ADDEND
M SETA 1 8 BITS PER BYTE
N SETA 128 STARTING COMPARAND X'80'
O SETA ICOPY CURRENT BYTE TO REVERSE
.BYTELP ANOP
AIF (O LT N).BYTEFT LESS THAN CURRENT - 0
O SETA O-N
J SETA J+L
.BYTEFT ANOP
L SETA L*2 NEXT ADDEND
N SETA N/2 NEXT COMPARAND
M SETA M+1 NEED EIGHT BITS
AIF (M LE 8).BYTELP
I SETA I+1
K SETA K+1
AIF (K LE 16).X16NXT
X SETC 'X'.'J'.')'
DC X
AIF (I LT 256).TABLOOP
MEND
--
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 18:57:04 -0400, Shmuel Metz (Seymour J.) wrote: 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. I received off-list a communication from an IBM employee explaining that the purpose is to gather statistics for quality control; it did not mention assigning priority of response. Yet I wonder, if the flaw had been discovered internal to IBM during engineering test, would it have been repaired (just because it's the right thing to do), or might schedule pressure have sent the product to market with the flaw. I doubt that the behavior I reported was tested; most likely that no one thought of the critical combination of inputs; less likely that it was deemed insufficiently important to test. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ECTG usage
The management of the CPU timer is completely in the realm of the dispatcher/scheduler. Therefore, using ECTG when you're not in an disabled state during the entire timing process will not produce the results you want. I have always used TIMEUSED to get CPU time. It's been many years since I've had a need for TIMEUSED and it has certainly changed. It appears ECTG was written to improve its performance. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richard Verville Sent: Thursday, July 25, 2013 8:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ECTG usage I'm trying to benchmark cputime (under CICS) with pieces of code I'm changing, ECTG before and ECTG after. I'm zeroing out operand 1 before the ECTG thus I get a negative value in GPR0(because ETCG subtracts the operand 1 with the timer value) after I'm doing a LCR of GPR0 to get the positive timer value. If the cputimer went negative during the test (timer interrupt), the second ECTG is higher than the 1st one and since I don't know the refeed value of the CPUTIMER, I can't tell how much cputime was spend. I know I could use CICS internal values or statistics) but since they made ECTG as non-privilege I figured I'd give it a try. So... I'm missing something in the concept (the refeed value and how many times the interrupt occured ?) Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
Hello Charles,
when looking at this code:
+@32L1395 DS 0H
+ LM r15,r0,EPA_WSA(r1,8)
+ LGHI r2,H'0'
+ ST r0,_CEECAA_(,r12,500)
+ ST r2,#MX_TEMP32(,r13,196)
+ LA r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
+ AHI r15,H'32'
it looks to me as if the optimizer decided to always call ffs with a
constant zero argument in the second case, see the LGHI to R2,
and ST R2 into the argument list - which is wrong IMO.
in the C code we have:
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
}
that is: if testWord is zero, then
it is computed to be the result of the shift,
but the generated machine code acts as if it stays as zero;
the shift and assignment to testWord is - for some reason -
moved out of the if - which is wrong, I believe.
What do others on the list who read ASSEMBLER and C think of this?
Maybe indeed a compiler problem?
Kind regards
Bernd
Am 25.07.2013 13:27, schrieb Charles Mills:
If anyone is better at this than I am and wants to bother with more
analysis, here is the LIST output of compiling the below. (Note that it is
inline, so here is where it is invoked.)
*int index = Utility::Ffs64(key);
LG r1,#SPILL0(,r13,448)
SRAG r0,r1,32
ST r0,valueToTest%33=32(,r13,416)
ST r1,valueToTest%33=32(,r13,420)
+ LG r0,valueToTest%33=32(,r13,416)
+ LTGR r0,r0
+ LGR r14,r0
+ BNE @32L1392
LGHI r3,H'0'
B@32L1393
+@32L1392 DS 0H
Lr1,ffs_ptr(,r6,908)
+ LTR r14,r14
+ BE @32L1395
+ ST r0,#MX_TEMP32(,r13,196)
+ LM r15,r0,EPA_WSA(r1,8)
+ ST r0,_CEECAA_(,r12,500)
+ LA r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
LGFR r3,r15
B@32L1393
+@32L1395 DS 0H
+ LM r15,r0,EPA_WSA(r1,8)
+ LGHI r2,H'0'
+ ST r0,_CEECAA_(,r12,500)
+ ST r2,#MX_TEMP32(,r13,196)
+ LA r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
+ AHI r15,H'32'
LGFR r3,r15
@32L1393 DS 0H
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Sunday, July 21, 2013 11: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.
WLM Report Class not cutting records
I'm observing a curious situation that I'm trying to understand. Note: I'm not the wlm sysprog or even an SME by any means, I'm just using the data from a performance aspect, so I hope this description is clear enough to muddle through. SERVICE_CLASS_1 = REPORT_CLASS_1,so no external stuff to gum up the example. If something runs under that service class, it gets reported in that report class. Everything was rolling along as expected until Monday. On Monday at 14:00, testing in that SC ended, so SERVICE_CLASS_1 = REPORT_CLASS_1 = 0 in the reporting periods following the testing halt (as expected). Both were still cutting records on 15 minute intervals even though they only contained zeros. On Monday at 15:25, the wlm guy activated a new policy. He swears the only change was to increase the resource cap of SERVICE_ CLASS_1. At the next reporting interval (15:30), SERVICE_CLASS_1 still has same behavior as prior to the change. It still cuts a record every 15 minutes, still containing zeros because no testing is occurring. However, the REPORT_CLASS_1 behavior has changed. There are no longer any records being cut for REPORT_CLASS_1 at all. Instead of a zero record, I get no record at all and haven't since 15:15 on Monday. WLM guy's theory is that when changes were activated, the buckets were emptied, and since there hasn't been any new activity since then, that there won't be any more records cut in REPORT_CLASS_1 until something actually comes in to that service class. I'm skeptical because there are still service class records being cut. I'm not knowledgeable enough to know whether the behavior should be the same or different for SC vs RC, whether it's a bug, or whether something botched up during the last policy change.And I can't seem to hit a meaningful search in the vile infocenter to find the correct manual to look at. If I can't find an explanation, I'm going to try to get a transaction executed to see if his theory is correct, but it's burdensome because this activity happens to be ddf transactions kicked off remotely on a different platform far far away. Thanks, tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blame COBOL (manual)
David Andrews wrote: On Thu, 2013-07-25 at 06:13 -0500, Elardus Engelbrecht wrote: with some meaningless IGYxxx messages. I'm sure that you meant ... with some *self-documenting* IGYxxx messages. Yeah, you're correct of course! I should wrote that ... (Dave pokes the wasp nest and runs.) Don't leave me, I'm running with you!!! [1] Groete / Greetings Elardus Engelbrecht [1] - About those wasps, here in South Africa, if you slap a nest off where-ever it is hanging, then as soon as those wasps (some species) see the nest is down, they stop stinging you. Until then they're after you for about 20 meters or so. Here in the bushveld, we sometimes made bets to see who can slap (with your bare hands of course!) the most nests down when it is really hot in the day and run away in half an hour without getting stung... ;-D Now, I'm older I'm leaving these stunts to younger guys... ;-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blame the COBOL, how cliché
Shiminsky, Gary wrote: The excuse that some of the COBOL code was corrupted is stupid. Really, has anyone ever seen decay or rust in any code? Hmmm, after scanning my ancient COBOL progs, they're still rust free! ;-) HSM can do wonders to package your libraries in rust-free migrated datasets, mind you... ;-D Every bug I have ever seen has been actually some programmer's mistake. Of course. Whoever gives a computer something faulty to do, it is that person's fault, not the computer. But then, someone (I wonder who?) said on IBM-MAIN, a COBOL program abended with a S??? abend, so it is not that program, it is the SYSTEM! It is the programmer's responsibility to fix his/her program if the issue is indeed within the program itself. Who-ever runs that program, has to fix anything else related to that abend or refer to the programmer if needed. 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
Re: Establishing and using Unix file system and USS under z/OS
One of the SYSUT1 DD statements needs to be SYSUT2. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of John McKown :: Sent: Thursday, July 25, 2013 5:43 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Establishing and using Unix file system and USS under z/OS :: :: That would be in the JCL manual. But there aren't any examples. And if :: you :: are not really UNIX literate, but just learning, it could be difficult :: to :: put together something useful. So I'll give an example, using IEBGENER. :: This will copy the READ macro from SYS1.MACLIB into a UNIX file in your :: home directory. :: :: //STEP1 EXEC PGM=IEBGENER :: //SYSPRINT DD SYSOUT=* OR WHATEVER :: //SYSIN DD DUMMY :: //SYSUT1 DD DISP=SHR,DSN=SYS1.MACLIB(READ), :: //SYSUT1 DD PATH='/u/myusername/READ.macro', :: // PATHOPTS=(OWRONLY,OTRUNC,OCREAT), :: // PATHMODE=(SIRUSR,SIWUSR), :: // FILEDATA=TEXT, :: // RECFM=FB,LRECL=80,BLKSIZE=0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Establishing and using Unix file system and USS under z/OS
OOPS! The UNIX file should be on SYSUT2. On Thu, Jul 25, 2013 at 10:34 AM, retired mainframer retired-mainfra...@q.com wrote: One of the SYSUT1 DD statements needs to be SYSUT2. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of John McKown :: Sent: Thursday, July 25, 2013 5:43 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Establishing and using Unix file system and USS under z/OS :: :: That would be in the JCL manual. But there aren't any examples. And if :: you :: are not really UNIX literate, but just learning, it could be difficult :: to :: put together something useful. So I'll give an example, using IEBGENER. :: This will copy the READ macro from SYS1.MACLIB into a UNIX file in your :: home directory. :: :: //STEP1 EXEC PGM=IEBGENER :: //SYSPRINT DD SYSOUT=* OR WHATEVER :: //SYSIN DD DUMMY :: //SYSUT1 DD DISP=SHR,DSN=SYS1.MACLIB(READ), :: //SYSUT1 DD PATH='/u/myusername/READ.macro', :: // PATHOPTS=(OWRONLY,OTRUNC,OCREAT), :: // PATHMODE=(SIRUSR,SIWUSR), :: // FILEDATA=TEXT, :: // RECFM=FB,LRECL=80,BLKSIZE=0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blame the COBOL, how cliché
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 07/24/2013 10:48:55 PM: From: scott svet...@ameritech.net The problem isn't the code, it's 1) The documentation for it - explaining how it was built, what was in it, and how it works - disappeared long ago. 2) Significant parts of the code have been ?corrupted.? 3) ?As time passes, the pool of COBOL expertise dwindles.? 4) The political will and military bureaucracy is not there. it is not just military, any bureaucracy that has hardening of the communication and/or cranial arteries. search Internet for blamestorming. aversion to change is sometimes rooted in fear. real change is radical, i.e. it goes to the roots (Latin radix, radicis for root) - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blame the COBOL, how cliché
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 07/25/2013 07:20:20 AM: From: Shiminsky, Gary gary.shimin...@doit.nh.gov COBOL is not at fault in this issue. It is incompetence. It is poor management, probably managers who shouldn't have been in data processing to begin with. How else would you loss all the documentation except for fire and water. COBOL, though fairly old, can be well written by a competent skilled programmers, having done that early on in my career. The excuse that some of the COBOL code was corrupted is stupid. Really, has anyone ever seen decay or rust in any code? Did it have bugs? No. Every bug I have ever seen has been actually some programmer's mistake. Gary Gary L. Shiminsky Senior zVM/zVSE Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-1509 Fax 603-271-1516 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system. -Original Message- From: Phil Smith III li...@akphs.com Reply-To: IBM List IBM-MAIN@LISTSERV.UA.EDU Date: Wednesday, July 24, 2013 4:34 PM To: IBM List IBM-MAIN@LISTSERV.UA.EDU Subject: Blame the COBOL, how cliché http://preview.reuters.com/2013/7/9/wounded-in-battle-stiffed-by-the-penta go n So the reason the payroll system is broken is because COBOL is ³old²? Sheesh. That¹s really weak? Oy, and they tried PeopleSoft as a replacement? -- 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 - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unsigned packed decimal
On 24 Jul 2013 02:20:25 -0700, in bit.listserv.ibm-main you wrote: Hello. I have a input file where the data is stored in unsigned packed decimal format, now i need the data to be moved to 9(4) field. Could someone let me know how the data is retrived? Is this the COBOL unsigned decimal format - PIC 9(4) PACKED-DECIMAL/COMP-3 which would be 0F in 3 bytes or a special format where just is stored. If it is the former all that is needed in COBOL is a simple MOVE between field with the appropriate pictures? Otherewise the other posters have made good suggestions. Clark Morris Thanks, Ron T -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
On 7/24/2013 7:17 PM, Paul Gilmartin wrote: As of 1.13, IEB[C]OPY is AC=0. (But there is an AC=1 version kept for those who feel they need it (why?).) IEWL (IEWBLINK) is AC=0. AMASPZAP is AC=01 (why?) AMASPZAP needs AC=1 to zap disk labels. It can be safely called in an unauthorized environment to perform the traditional function of zapping load modules and program objects. AMASPZAP is not an impediment to an unauthorized SMP/E. I believe that as of z/OS 1.13 *none* of the programs invoked by SMP/E require authorization. But, as you pointed out in an earlier post, SMP/E itself uses Wait for DSNAME in dynamic allocation, which does require authorization. That's a minor and rarely-needed feature but, if it's important to someone, I believe it would not be very difficult to provide this capability in a way that does not require SMP/E to be authorized. Of course any program that runs AC=1 assumes the responsibility of performing its own SAF checking. I believe this is true also for any program linked AC=0 into an APF authorized library where it may be attached by an AC=1 program. I think the real problem is the fact that SMPE somehow abuses APF to bypass normal security checks for some of its processing. Until IBM decides to correct that (removing APF seems like it would be effective but also seems like overkill), an equitable solution that addresses the needs of both sysprogs and non-sysprogs is likely to be elusive. Why overkill? If it's unnecessary, it's safer and more useful without it. abuses? It's possible. It's possible that development added a new function and hadn't the resources to code the necessary SAF checks. It's even possible that some specified function of SMP/E requires bypassing normal security checks, although that seems highly unlikely. SMP/E is not a self-contained, APF authorized program. It invokes various utilities (in fact, any program you choose!) that were *never* intended to run authorized and therein lies the problem. You cannot change the rules of MVS to require that every unauthorized program residing in an authorized library follow the rules for authorized programs on the off-chance that one of them might one day be invoked by SMP/E in an authorized environment. That would be lunacy. -- 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
z/OS 2.1 Program Product number
Hello Group, I will be ordering z/OS 2.1 after September. Is there any document or weblink, which can help me to find a list of all program numbers of products that we would need with z/OS v2.1. Thanks Regards Sourabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old Linklist set use after new set activation
The OP's scenario is likely incomplete and/or in some way inaccurate. If you restart a task that has no bearing on anything. If you start a new address space, or start a new job in an initiator, that new work unit will be using the now-current LNKLST. Peter Relson z/OS Core Technology Design rel...@us.ibm.com 1-845-435-83908+295-8390 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 Program Product number
Will you be using Shop zSeries to order? If so, the product numbers should be in the drop down (I think). You provide the current feature list you have in SMP/E to the function and it lists the products you need. That will not help if you are going to add products. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of saurabh khandelwal Sent: Thursday, July 25, 2013 9:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 Program Product number Hello Group, I will be ordering z/OS 2.1 after September. Is there any document or weblink, which can help me to find a list of all program numbers of products that we would need with z/OS v2.1. Thanks Regards Sourabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 Program Product number
Hello Lizette, As of now, IBM has not announced z/OS 2.1. So we can not go to shop zSeries to get program id. Do we have any other to find product number now. Regards Saurabh On Thu, Jul 25, 2013 at 9:49 PM, Lizette Koehler stars...@mindspring.comwrote: Will you be using Shop zSeries to order? If so, the product numbers should be in the drop down (I think). You provide the current feature list you have in SMP/E to the function and it lists the products you need. That will not help if you are going to add products. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of saurabh khandelwal Sent: Thursday, July 25, 2013 9:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 2.1 Program Product number Hello Group, I will be ordering z/OS 2.1 after September. Is there any document or weblink, which can help me to find a list of all program numbers of products that we would need with z/OS v2.1. Thanks Regards Sourabh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blame the COBOL, how cliché
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 07/25/2013 12:24:26 PM: From: Frank Swarbrick frank.swarbr...@yahoo.com I wonder, exactly, how code is corrupted. Does it start fading away as it ages? :-( While we cannot read the mind of the author of that statement, code becomes corrupted over time when maintenance is done sloppily and violates the design of the program/system. I think technical debt is appropriate. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a reverse bits hardware instruction?
The overhead of a macro generated table versus static DC-generated table
would only be an issue if the code is reassembled on a very frequent
basis. Even if that is the case, that still doesn't rule out using an
Assembler macro to generate the table for the first assembly, then using
cut paste to put the generated DC's into the code and comment out the
macro invocation. That way you can even keep the generation macro in
the code as documentation and not have to track or document a separate
program.
I had to consult the Assembler Reference to be sure I knew what I was
doing, but using the Arithmetic AND one can create a simpler version of
the generation macro that eliminates the innermost bit loop. I tested
the version below with z390:
MACRO
.* GENERATE TRT TABLE, 16 BYTES PER DC, FOR REVERSING BITS IN BYTE
LABEL REVTBL
LCLA N,R,SMAX
LCLC X,SEP
LABEL DS 0D
N SETA 0 BYTE OFFSET IN TABLE
.TLOOP ANOP
SMAX SETA N+16 LIMIT FOR NEXT DC STATEMENT GEN
X SETC '' CUMULATIVE AL1 CONSTANTS NXT DC
SEP SETC '' NO COMMA NEEDED FOR 1ST AL1 IN DC
.SLOOP ANOP
.* COMPUTE REVERSED BITS FOR N
R SETA ((N AND 128)/128)+((N AND 64)/32)+((N AND 32)/8)
R SETA R+((N AND 16)/2)+((N AND 8)*2)+((N AND 4)*8)
R SETA R+((N AND 2)*32)+((N AND 1)*128)
X SETC 'X.SEP.R' ADD NEXT AL1 CONSTANT
SEP SETC ',' NEXT TIME WILL NEED COMMA
N SETA N+1 ADVANCE NXT TABLE BYTE
AIF (N LT SMAX).SLOOP IF MORE FOR CURRENT DC
DC AL1(X.)
AIF (N LT 256).TLOOPIF MORE DC'S LEFT
MEND
The first and last 16 generated table bytes from the above macro are:
DC AL1(0,128,64,192,32,160,96,224,16,144,80,208,48,176,112,240)
...
DC AL1(15,143,79,207,47,175,111,239,31,159,95,223,63,191,127,255)
which are consistent with the original macro.
Joel C. Ewing
On 07/24/2013 12:54 PM, Kenneth Wilkerson wrote:
The macro at the end of my reply will generate a reverse translate table. I
tested it enough to see that it looked right but it has nothing to do with
my original point. I've found this discussion interesting and it has given
me reason to play with something other than the complex process I'm working
on now. My original point, as was taken by Charles, was that I prefer
automatic processes to generate anything but the simplest translate tables.
I prefer to do it in a program and copy it from a dump into a program
because the table is static. I don't need to generate it every time I
assemble.
In regards to TROO, the original problem was stated as translating a 64 bit
register. A STG, TR for 8 bytes, followed by a LRVG will more than suffice.
Though, I find your argument about the use of a TRTRE to simulate a FROGR
interesting. It brings the whole bit reversal into perspective. I'm not a
big fan of translate instructions (I use them often enough), particularly
those that require facilities and facility enhancements, unless you're
translating long strings and are willing to test the facility bits. I'm
sure that the translation and parsing facilities exist on most customer's
boxes by now but I emphasize most. When I awakened this morning, I wrote
an algorithm to do a load reverse bytes and bits using FLOGR to drive the
process. I'm going to give the idea of a FROGR simulation more thought and
continue this exercise later.
MACRO
LABEL REVTABLE ,
* Construct reverse bits translate table
LCLA I,J,K,L,M,N,O
LCLC X
LABEL DS 0DLIKE EM DOUBLE WORD ALIGNED
I SETA 0 STARTING VALUE
.TABLOOP ANOP LOOP UNTIL TABLE IS DONE
K SETA 1 NEED SIXTEEN ENTRIES PER LINE
X SETC 'AL1('
AGO.X16LP
.X16NXT ANOP
X SETC 'X'.'J'.','
.X16LP ANOP 16 ENTRY LOOP
J SETA 0 STARTING RESULT
L SETA 1 STARTING ADDEND
M SETA 1 8 BITS PER BYTE
N SETA 128 STARTING COMPARAND X'80'
O SETA ICOPY CURRENT BYTE TO REVERSE
.BYTELP ANOP
AIF (O LT N).BYTEFT LESS THAN CURRENT - 0
O SETA O-N
J SETA J+L
.BYTEFT ANOP
L SETA L*2 NEXT ADDEND
N SETA N/2 NEXT COMPARAND
M SETA M+1 NEED EIGHT BITS
AIF (M LE 8).BYTELP
I SETA I+1
K SETA K+1
AIF (K LE 16).X16NXT
X SETC 'X'.'J'.')'
DC X
AIF (I LT 256).TABLOOP
MEND
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Wednesday, July 24, 2013 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there a reverse bits hardware instruction?
The construction of arbitrary translation tables can be error-prone, and
when it is it is better done procedurally. I use the HLASM macro language,
which is entirely adequate to such tasks; mais à chacun son goût.
Here, however, we have for a TROO only the 256 permutations taken two at a
time of the
Re: z/OS 2.1 Program Product number
On 7/25/2013 9:25 AM, saurabh khandelwal wrote: As of now, IBM has not announced z/OS 2.1. As of when?! The z/OS 2.1 announcement and zBC12 launch occurred Tuesday. The product number is 5650-ZOS. -- 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: z/OS 2.1 Program Product number
On 7/25/2013 10:58 AM, Ed Jaffe wrote: On 7/25/2013 9:25 AM, saurabh khandelwal wrote: As of now, IBM has not announced z/OS 2.1. As of when?! The z/OS 2.1 announcement and zBC12 launch occurred Tuesday. The product number is 5650-ZOS. Well, z/OS 2.1 was announced on Feb. 5, 2013; the zBC12 launch did indeed occur Tuesday. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 Program Product number
saurabh khandelwal wrote: Hello Lizette, As of now, IBM has not announced z/OS 2.1. So we can not go to shop zSeries to get program id. Do we have any other to find product number now. We announced z/OS V2.1 availability on Tuesday. The product number is 5650-ZOS. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 Program Product number
Hello Edward, I am looking for program numbers of products that we would need with z/OS v2.1 . This typically includes: VS Fortran C/370 Library REXX Compiler/Lib Netview for z/OS Tivoli Mgmt Services etc... Regards Saurabh On Thu, Jul 25, 2013 at 10:28 PM, Ed Jaffe edja...@phoenixsoftware.comwrote: On 7/25/2013 9:25 AM, saurabh khandelwal wrote: As of now, IBM has not announced z/OS 2.1. As of when?! The z/OS 2.1 announcement and zBC12 launch occurred Tuesday. The product number is 5650-ZOS. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.**com/ 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 -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 Program Product number
OMG. 5650-ZOS, I missed that one! Love it!! MA On Thu, 25 Jul 2013 13:04:35 -0400, John Eells ee...@us.ibm.com wrote: We announced z/OS V2.1 availability on Tuesday. The product number is 5650-ZOS. -- 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 Jul 25, 2013, at 8:05 AM, Shmuel Metz (Seymour J.) wrote: Of course that is an issue and there is a basic rule to follow. DOCUMENT, DOCUMENT, DOCUMENT. I have been able to pick up on install with 1 piece of paper and maybe a tape. I have seen installations send an object deck on a tape (another extreme was an object deck in punched cards!) the person who installed one product hid it in an undocumented CSI and it took some digging just to find the CSI as he didn't bother to document it, I had to guess the name. What a PITA. Of course he was a short term consultant. Since then I have suggested the consultants stay away from installs. Ed I've sometimes had to spend time figuring out what the correct CSI is. SMP/E can be very nice, but their is still a role for documentation. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 Program Product number
Hello Mar, This is only for z/OS. How about other product program number associated with z/OS, as I mentioned in previous email. VS Fortran C/370 Library REXX Compiler/Lib Netview for z/OS Tivoli Mgmt Services etc.. Regards Saurabh On Thu, Jul 25, 2013 at 10:52 PM, Mary Anne Matyaz maryanne4...@gmail.comwrote: OMG. 5650-ZOS, I missed that one! Love it!! MA On Thu, 25 Jul 2013 13:04:35 -0400, John Eells ee...@us.ibm.com wrote: We announced z/OS V2.1 availability on Tuesday. The product number is 5650-ZOS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- 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 Thu, 25 Jul 2013 08:54:34 -0700, Ed Jaffe wrote: SMP/E is not a self-contained, APF authorized program. It invokes various utilities (in fact, any program you choose!) that were *never* intended to run authorized and therein lies the problem. But those programs must come from authorized libraries, else SMP/E ABENDs. And it is the installation's responsibility to protect authorized libraries. But read on ... You cannot change the rules of MVS to require that every unauthorized program residing in an authorized library follow the rules for authorized programs on the off-chance that one of them might one day be invoked by SMP/E in an authorized environment. That would be lunacy. Back in the day, wasn't it impossible for LINKLIST to contain a mixture of authorized and unauthorized libraries? (Aren't things better nowadays?) So programs to go in LINKLIST were, willy-nilly, placed in authorized libraries. Add inertia to get to the present situation. Is SMP/E the only (IBM-supplied) authorized program that allows the user to specify utility names (in fact, any program you choose!)? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blame the COBOL, how cliché
On 7/25/2013 11:53 AM, Kirk Talman wrote: Every bug I have ever seen has been actually some programmer's mistake. Then you just haven't been around long enough g Back in the fifties and sixties, plenty of failures occurred due to machine errors. And some happened due to C.E. errors - in the seventies we had an extra 2MiB of slow memory on one machine, but the C.E. forgot to enable memory protection, so any errant program could overwrite foreign memory. Luckily I found the problem before our customers did. And some happened due to microcode errors. In the eighties we got a 4341, only to find ourselves unable to log on to TSO - it would 0C4 consistently. It took me a while to track this down - the MVCK instruction would fail when a string was split over a 2KiB boundary that wasn't a 4KiB multiple. Some time later we got a new floppy, and it still failed; IBM fixed the condition of one split string, but not the case when both were split. Some time later we upgraded to a 4381 - one of the first things I ran was my MVCK test program; yep, it failed. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Blame the COBOL, how cliché
Seems like what the bugs you experienced back then were more related to hardware malfunctions than actual programming errors. When I was in the Army in Korea we ran on Univac 1004 card processors. Occasionally the program card decks would would have problems due to wear and tear from going through the card readers. Gary Gary L. Shiminsky Senior zVM/zVSE Systems Programmer Mainframe Technical Support Group Department of Information Technology State of New Hampshire 27 Hazen Drive Concord, NH 03301 603-271-1509 Fax 603-271-1516 Statement of Confidentiality: The contents of this message are confidential. Any unauthorized disclosure, reproduction, use or dissemination (either whole or in part) is prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete the message from your system. -Original Message- From: Gerhard Postpischil gerh...@valley.net Reply-To: IBM List IBM-MAIN@LISTSERV.UA.EDU Date: Thursday, July 25, 2013 2:25 PM To: IBM List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Blame the COBOL, how cliché On 7/25/2013 11:53 AM, Kirk Talman wrote: Every bug I have ever seen has been actually some programmer's mistake. Then you just haven't been around long enough g Back in the fifties and sixties, plenty of failures occurred due to machine errors. And some happened due to C.E. errors - in the seventies we had an extra 2MiB of slow memory on one machine, but the C.E. forgot to enable memory protection, so any errant program could overwrite foreign memory. Luckily I found the problem before our customers did. And some happened due to microcode errors. In the eighties we got a 4341, only to find ourselves unable to log on to TSO - it would 0C4 consistently. It took me a while to track this down - the MVCK instruction would fail when a string was split over a 2KiB boundary that wasn't a 4KiB multiple. Some time later we got a new floppy, and it still failed; IBM fixed the condition of one split string, but not the case when both were split. Some time later we upgraded to a 4381 - one of the first things I ran was my MVCK test program; yep, it failed. Gerhard Postpischil Bradford, Vermont -- 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
SMF, Assembler, s_float, l_float, float Examples
I have a prohram that prints some specific SMF data, that I use for charting graphing. I am running into some SMF fields that are listed in the SMF manual as s_float, l_float, float ... my assumption is that these are hex float fields? A good example can be seen in the SMF 74(5) records. I was wondering if anyone out there had some examples of assembler code where they converted these fields to standard EBCDIC 1,234.56 format.. I am finding some very complex methods, but dont really need to actively add, multilpy, or devide,, just convert .. Any assistance and/or advise would be greatly appreciated! Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF, Assembler, s_float, l_float, float Examples
You'll probably want to use the CFDR instruction to convert from floating point to fixed point. After that it would be a standard CVD and EDIT instructions to produce the printed result. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dr Rick Williams Sent: Thursday, July 25, 2013 12:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF, Assembler, s_float, l_float, float Examples I have a prohram that prints some specific SMF data, that I use for charting graphing. I am running into some SMF fields that are listed in the SMF manual as s_float, l_float, float ... my assumption is that these are hex float fields? A good example can be seen in the SMF 74(5) records. I was wondering if anyone out there had some examples of assembler code where they converted these fields to standard EBCDIC 1,234.56 format.. I am finding some very complex methods, but dont really need to actively add, multilpy, or devide,, just convert .. Any assistance and/or advise would be greatly appreciated! 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: SMF, Assembler, s_float, l_float, float Examples
I'm too lazy to all that work. I cheat (a lot). But my cheating does require that my HLASM code be LE enabled, or use CEEPIPI to establish an LE environment. I find the former to be easier. Once I do that, I can use the C subroutine SPRINTF to do my conversion from floating point to printable. Well, I don't actually do floating point. I do other conversions. The C calling sequence is a bit of a bother, but once learned, it is not too difficult to use. On more recent z machines (but I don't know what level) there is an HFP convert to fixed set of instructions. However, they round to an integer. So you'd need to scale the floating point by multiplying by an appropriate factor of 10 before doing the instruction. The instructions are CFER - short HFP to 32 bit integer CFDR - long HFP to 32 bit integer CFXR - extended HFP to 32 bit integer CGER - short HFP to 64 bit integer CGDR - long HFP to 64 bit integer CGXR - extended HFP to 64 bit integer These are all opcode gen_register,mask,float_register where mask specifies the rounding 0 - towards 0 1 - invalid 2 - invalid 3 - invalid 4 - to nearest, ties go towards zero 5 - to nearest, ties go towards even 6 - to +inf 7 - to -inf On Thu, Jul 25, 2013 at 2:38 PM, Dr Rick Williams dr.rick.willi...@gmail.com wrote: I have a prohram that prints some specific SMF data, that I use for charting graphing. I am running into some SMF fields that are listed in the SMF manual as s_float, l_float, float ... my assumption is that these are hex float fields? A good example can be seen in the SMF 74(5) records. I was wondering if anyone out there had some examples of assembler code where they converted these fields to standard EBCDIC 1,234.56 format.. I am finding some very complex methods, but dont really need to actively add, multilpy, or devide,, just convert .. Any assistance and/or advise would be greatly appreciated! Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a reverse bits hardware instruction?
In CAE1XxDGgBNuZr4gv30WtG27jj4jqVLjBM0-qmCXOf=rz8x6...@mail.gmail.com, on 07/23/2013 at 07:11 PM, John Gilmore jwgli...@gmail.com said: Look at the Rotate instructions in the PrOp. RLL will do come close to doing what you want to do. FSVO close. Rotate has noting to do with reversing the bit order; it's just a circular shift. -- 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: Is there a reverse bits hardware instruction?
In 000b01ce87ee$711f3580$535da080$@mcn.org, on 07/23/2013 at 05:49 PM, Charles Mills charl...@mcn.org said: I guess you could do it with TR (to reverse the bits) and then LRVG (to reverse the bytes) but that is overly complex and probably slow (IMHO). It's faster than move inverse, translate and load (-; -- 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: Is there a reverse bits hardware instruction?
In 1482096876342980.wa.paulgboulderaim@listserv.ua.edu, on 07/24/2013 at 09:25 AM, Paul Gilmartin paulgboul...@aim.com said: One TR to reverse the bytes, Why, Isn't LRVG a lor faster and more concise? -- 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: Is there a reverse bits hardware instruction?
In 51ef18aa.2060...@gmail.com, on 07/24/2013 at 07:58 AM, David Crayford dcrayf...@gmail.com said: There's a RLLG instruction to rotate the bits in a 64-bit integer. It doesn't *reverse* the bits, which is what the OP needs. -- 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: Is there a reverse bits hardware instruction?
In 023901ce8876$0099c900$01cd5b00$@mcn.org, on 07/24/2013 at 09:59 AM, Charles Mills charl...@mcn.org said: Agreed in principle. I would probably use Rexx to create it. I would create the TR table in a macro, or the inline equivalent. -- 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: Is there a reverse bits hardware instruction?
In CAE1XxDHWvp88UB4cB69Z0JbDaFE4mtv4eB+ViH=s3xxcttf...@mail.gmail.com, on 07/24/2013 at 11:29 AM, John Gilmore jwgli...@gmail.com said: Here, however, we have for a TROO Why TROO rather than TR? -- 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: Is there a reverse bits hardware instruction?
In cae1xxdhosowjbjwsbdfaqjtt2namcqjsbg2y78y7heomz3a...@mail.gmail.com, on 07/23/2013 at 08:07 PM, John Gilmore jwgli...@gmail.com said: I am happy to have David join in my recommendation, and I can imagine a circumstance in which RLLG would be more useful than RLL, but RLL itself does 64-bit rotations. For ROTATE LEFT SINGLE LOGICAL (RLL), bits 0-31 of general registers R1 and R3 remain unchanged. -- 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: SMP/E vs. NON SMPE Installs (Was BLKSIZE=3120)
In 014401ce887f$d11bb080$73531180$@mindspring.com, on 07/24/2013 at 08:09 AM, Lizette Koehler stars...@mindspring.com said: I do not want them to be able to rec/app/acc fixes on my zones. Then don't give them write access to the data sets in your zone. -- 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
Calling Cobol subroutine from EasyTrieve
Hi all, I am calling a Cobol subroutine from an Easytrieve program. Is there a known limit to the amount of data that can be exchanged in this scenario? I'm running into two limitations We wrote test programs to test easytrieve calling a sub program with a linkage section of 44,000 bytes. The sub program just moves working storage initialized to all X’s to the linkage section. The sub program runs fine when called by a COBOL program but will ABEND when called by easytrieve. When we lower the size of the linkage section in the sub program to 34,000 bytes, it will run from easytrieve but it gives an abend IEA705I ERROR DURING FREEMAIN SYS CODE = 878-18 when I try to display the data. Thanks! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MAXSPACE and central storage
Greetings , We have a requirement in our shop to change the MAXSPACE value from 2000M to 8000M . IBM says there should be a 1:3 ratio between maxspace and auxiliary storage . that means , my total auxiliary storage needs to be increased by 3 times which is 24000 M (to satisfy 1:3 ratio) . I did that as well . Now my concern is that my Central storage is 5690 M and will it create any problem once i set the maxspace to 8000 M .I couldn't find any documentation which says central storage should be increased . I'm trying to understand how DUMPSRV address space works when it is allowed to capture a dump of 8000M in size considering my central and local page dataset sizes given above . we are on z/os 1.11 and thus AUXMGMT is set as ON by default . Please share your thoughts on this . Thanks in Advance , Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a reverse bits hardware instruction?
So, no need for any macro at all to generate the byte bit reversal TRT
table! I must have skipped over or forgotten the 2003 posting.
This is just totally awesome, especially the redundant unary +'s to
force decent alignment for readability. Had to actually run it with
PRINT DATA to convince myself it really worked, then study it more
closely. Once you understand why it is syntactically correct and what
it is doing it seems obvious, but at first sight it is certainly
intimidating. Obviously usage in a production application should have
some explanatory comments so future maintainers don't panic at their
first exposure!
Joel C Ewing
On 07/25/2013 09:13 AM, Victor Gil wrote:
Here's a single DC instruction I've posted May 2003 [search for what's your
most difficult assembler concept]
BYTE_FLIP DS 0CL256
TDC 256AL1*-T)/001)-((*-T)/002)*2)*X'80'
(((*-T)/002)-((*-T)/004)*2)*X'40'
(((*-T)/004)-((*-T)/008)*2)*X'20'
(((*-T)/008)-((*-T)/016)*2)*X'10'
(((*-T)/016)-((*-T)/032)*2)*X'08'
(((*-T)/032)-((*-T)/064)*2)*X'04'
(((*-T)/064)-((*-T)/128)*2)*X'02'
(((*-T)/128)-((*-T)/256)*2)*X'01')
HTH,
-Victor-
---
The macro at the end of my reply will generate a reverse translate table. I
tested it enough to see that it looked right but it has nothing to do with
my original point. I've found this discussion interesting and it has given
me reason to play with something other than the complex process I'm working
on now. My original point, as was taken by Charles, was that I prefer
automatic processes to generate anything but the simplest translate tables.
I prefer to do it in a program and copy it from a dump into a program
because the table is static. I don't need to generate it every time I
assemble.
In regards to TROO, the original problem was stated as translating a 64 bit
register. A STG, TR for 8 bytes, followed by a LRVG will more than suffice.
Though, I find your argument about the use of a TRTRE to simulate a FROGR
interesting. It brings the whole bit reversal into perspective. I'm not a
big fan of translate instructions (I use them often enough), particularly
those that require facilities and facility enhancements, unless you're
translating long strings and are willing to test the facility bits. I'm
sure that the translation and parsing facilities exist on most customer's
boxes by now but I emphasize most. When I awakened this morning, I wrote
an algorithm to do a load reverse bytes and bits using FLOGR to drive the
process. I'm going to give the idea of a FROGR simulation more thought and
continue this exercise later.
MACRO
LABEL REVTABLE ,
* Construct reverse bits translate table
LCLA I,J,K,L,M,N,O
LCLC X
LABEL DS 0DLIKE EM DOUBLE WORD ALIGNED
I SETA 0 STARTING VALUE
.TABLOOP ANOP LOOP UNTIL TABLE IS DONE
K SETA 1 NEED SIXTEEN ENTRIES PER LINE
X SETC 'AL1('
AGO.X16LP
.X16NXT ANOP
X SETC 'X'.'J'.','
.X16LP ANOP 16 ENTRY LOOP
J SETA 0 STARTING RESULT
L SETA 1 STARTING ADDEND
M SETA 1 8 BITS PER BYTE
N SETA 128 STARTING COMPARAND X'80'
O SETA ICOPY CURRENT BYTE TO REVERSE
.BYTELP ANOP
AIF (O LT N).BYTEFT LESS THAN CURRENT - 0
O SETA O-N
J SETA J+L
.BYTEFT ANOP
L SETA L*2 NEXT ADDEND
N SETA N/2 NEXT COMPARAND
M SETA M+1 NEED EIGHT BITS
AIF (M LE 8).BYTELP
I SETA I+1
K SETA K+1
AIF (K LE 16).X16NXT
X SETC 'X'.'J'.')'
DC X
AIF (I LT 256).TABLOOP
MEND
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
Joel C. Ewing,Bentonville, AR jcew...@acm.org
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Looks similar to the HUGE problem (g) with having old catalogs still defined with IMBED and REPLICATE. Another hanger-on from days of yore that no one deemed worthy to keep current with changing technology. Bill Fairchild Franklin, TN - Original Message - From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, July 22, 2013 12:28:26 PM Subject: Re: BLKSIZE=3120 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. ... LOGDSNAME 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. /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: Looking for help with an obscure C integer problem
I think I see your problem. Try compiling with LANGLVL(LONGLONG).
On 22/07/2013, at 12:17 PM, Charles Mills charl...@mcn.org wrote:
Perhaps more to the point, here are my exact options, minus only some
comments:
TARG(LE,zOSV1R9)
# On 1/10/11 X Y wrote that Z was on z990s
ARCH(6)
# Force most enums to be integers for consistency
ENUMSIZ(INT)
# Test of several optimization options
AGGRCOPY HGPR LIBANSI
# Some new optimization -- suspect these if problem!
ROCONST
# TEST Seems to hose up the linker if CSECT also specified
# Uncomment to show macros -- *** V1R13 and above ***
# SHOWM LIST PPONLY
# Try suppressing the multi-character literal warning for Events
SUPP(CCN5802)
# NODLL may be necessary to make the program COBOL-loadable
NODLL
# XPL(OSCALL(U)) OBJECTMODEL(IBM)
# Set the following based on optimization desired
# 0 and NOINLINE TEST or 2 and INLINE NOTEST
# OPT(0) NOINLINE TEST GONUMBER
OPT(2) INLINE NOTEST NOGONUMBER COMPRESS
# 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: Looking for help with an obscure C integer problem
I guess that LANGLVL(LONGLONG) is already in effect,
because LANGLVL(LONGLONG) is implicitly set with LANGLVL(EXTENDED);
if not, the compiler would not accept the long long declarations, I guess,
and it handles the long long variables in the beginning of the function
as 64 bit values (see the SRAG).
I examined the whole ASSEMBLER resolution of the function, and everything
is fine IMO with the only exception that the shift of the original 64
bit value
in the else part yielding testWord is not present - instead ffs in the
else part
is called with a constant zero parameter.
If this is really the ASSEMBLER resolution of the C source, this is a
compiler
error IMO.
For further examination Charles could maybe send me the compile listing
of this function offline (if it is not too large) - with the LIST option
set.
Or: if this is really a matter of the missing LANGLVL(LONGLONG), we should
see how the ASSEMBLER resolution changes when LANGLVL(LONGLONG)
is added.
Kind regards
Bernd
Am 26.07.2013 01:41, schrieb David Crayford:
I think I see your problem. Try compiling with LANGLVL(LONGLONG).
On 22/07/2013, at 12:17 PM, Charles Mills charl...@mcn.org wrote:
Perhaps more to the point, here are my exact options, minus only some
comments:
TARG(LE,zOSV1R9)
# On 1/10/11 X Y wrote that Z was on z990s
ARCH(6)
# Force most enums to be integers for consistency
ENUMSIZ(INT)
# Test of several optimization options
AGGRCOPY HGPR LIBANSI
# Some new optimization -- suspect these if problem!
ROCONST
# TEST Seems to hose up the linker if CSECT also specified
# Uncomment to show macros -- *** V1R13 and above ***
# SHOWM LIST PPONLY
# Try suppressing the multi-character literal warning for Events
SUPP(CCN5802)
# NODLL may be necessary to make the program COBOL-loadable
NODLL
# XPL(OSCALL(U)) OBJECTMODEL(IBM)
# Set the following based on optimization desired
# 0 and NOINLINE TEST or 2 and INLINE NOTEST
# OPT(0) NOINLINE TEST GONUMBER
OPT(2) INLINE NOTEST NOGONUMBER COMPRESS
# 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
Re: BLKSIZE=3120
On Mon, 22 Jul 2013 15:32:37 -0400, Jim Mulder wrote: 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? 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. There's a precedent for IBM's accepting APARs against products that thwart SDB. From OW43702: PROBLEM CONCLUSION: Module IRXIOLAR has been changed to allow the specification of BLKSIZE=0 for the TSO/E REXX command EXECIO in order to allow the user to specify system determined block size. I don't know how much a precedent is worth, nor what IBM's policy is in such cases. And it did break things, incidentally fixed by OW46399: ERROR DESCRIPTION: ABEND013-20 opening subsystem dataset. The blksize passed to open was 0. The lrecl was other than 80. Open processing does not select a proper default. RC20 MSGIEC141I IGG0199G PROBLEM CONCLUSION: Code modified to change the default blksize calculation to take into account the lrecl specified. I asked IBM to mark OW43702 PE, fixed by OW46399. IBM declined, calling OW43702 WAD. I saved the entire ugly transcript. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
On 26/07/2013 8:36 AM, Bernd Oppolzer wrote: I guess that LANGLVL(LONGLONG) is already in effect, because LANGLVL(LONGLONG) is implicitly set with LANGLVL(EXTENDED); if not, the compiler would not accept the long long declarations, I guess, and it handles the long long variables in the beginning of the function as 64 bit values (see the SRAG). I agree. I couldn't see a LANGLVL(LONGLONG). I compile using LANGLVL(EXTENDED0X) and LONGLONG is not the default. -- 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)
Back when IBM created the FACILITY class resource names for SMPE I surmised there was an obscure hole through which a zone dataset could be updated despite lack of update access via the dataset profile. I started to experiment with a test CSI to try to hack into an answer. I would have been in the position of the minister that sinks a hole-in-one on the Sabbath. Who'd believe me and who can I tell? Lack of time and the company's eagerness to show me the door prevailed. On 7/25/2013 9:47 AM, Shmuel Metz (Seymour J.) wrote: In 014401ce887f$d11bb080$73531180$@mindspring.com, on 07/24/2013 at 08:09 AM, Lizette Koehler stars...@mindspring.com said: I do not want them to be able to rec/app/acc fixes on my zones. Then don't give them write access to the data sets in your zone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Establishing and using Unix file system and USS under z/OS
I'm still trying to look at how I might due a REXX interface to PCRE. But I'm not sleeping well due to a sick dog and so just don't have much extra energy after work. I do now have access to a remote system with a C license. But I might actually find it easier to us HLASM and a CEEPIPI environment, rather than C. On Jul 25, 2013 8:43 PM, Ze'ev Atlas zatl...@yahoo.com wrote: Gentlemen The example and explanations are exactly what I needed to give me the head start (and now I can go to the manual and have some better understanding of details if I need them :) I caught the SYSUT1/SYSUT2 issue and assumed right away that it was a typo. Thank you so much Now - with your help, adding the functionality of deciding what type of file I am looking at (using fldata) and sending it to the correct piece of code seems much less intimidating. HFS files and flat files will pretty much go to the existing Unix oriented code and dealing with PDS is pretty much coded and tested. I will try to code the additional functions in most generic way and since it is open source, it probably could be used all over. It will be shipped with the next version of PCRE for z/OS project. Ze'ev Atlas PCRE for z/OS Open Source project Volunteers are welcome Still in need for analyzing, designing and implementing Rexx interface! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLKSIZE=3120
Maybe they are keeping current; NOT worrying about differences that are moot? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: DASDBILL2 dasdbi...@comcast.net Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 25 Jul 2013 22:42:06 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: BLKSIZE=3120 Looks similar to the HUGE problem (g) with having old catalogs still defined with IMBED and REPLICATE. Another hanger-on from days of yore that no one deemed worthy to keep current with changing technology. Bill Fairchild Franklin, TN - Original Message - From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, July 22, 2013 12:28:26 PM Subject: Re: BLKSIZE=3120 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. ... LOGDSNAME 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. /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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.1 Program Product number
Hello David, As I mentioned in previous email, I am looking product program number associated with z/OS 2.1 as well. Some of the products are as below, which I am not able to find any where. Can you please help getting document or any weblink. VS Fortran C/370 Library REXX Compiler/Lib Netview for z/OS Tivoli Mgmt Services etc.. Regards Saurabh On Thu, Jul 25, 2013 at 11:27 PM, David Andrews d...@lists.duda.com wrote: On Thu, 2013-07-25 at 23:01 +0530, saurabh khandelwal wrote: How about other product program number associated with z/OS, as I mentioned in previous email. VS Fortran C/370 Library REXX Compiler/Lib Netview for z/OS Tivoli Mgmt Services etc.. Many program numbers seem to have been consolidated into 5650-ZOS, with differentiating entitlement identifiers. See the Terms and conditions section of the announcement letter. -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Thanks Regards Saurabh Khandelwal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WLM managed workload
Thanks Kees Ituriel, Still i am struggling to tell WLM how PI of a workload may have different acceptance level on different LPARs. For Me I just would like WLM to schedule workload on one LPAR unless that LPAR can't run it or is not available. I know i can do that by establishing/ controlling RESOURCE group / Scheduling environment via MVS commands but would be easier If i can define this rule within WLM policies. Thanks for your help. regards Munif. -- 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 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? I looked at the current TRANSMIT/RECEIVE code, and it still specifies BLKSIZE=3120 when it creates a LOG data set, and still hardcodes BLKSIZE=3120 on its DCB for the log data set. I engaged in battle with the former TSO developers a long time ago (maybe over 20 years ago, maybe even before the advent of System Determined Blocksize). I wanted them to at least remove the BLKSIZE=3120 on the DCB so that if someone (like me) was sensible enough to allocate his own log dataset with an efficient BLKSIZE, TRANSMIT/RECEIVE would cease to override that on the DCB and thus no longer change the BLKSIZE to 3120. Since the stupid DCB specification is still there, exists, I apparently lost that battle. 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: z/OS 2.1 Program Product number
As mentioned, the IBM program number for z/OS Version 2 is 5650-ZOS. (That's five six five zero zee/zed oh ess. Watch out for the zero versus oh.) There are many optional z/OS elements which share the same program number. Two of them (z/OS Security Level 3 and Communications Server Security Level 3) are available for ordering at no additional charge. There are also some no additional charge features which do not share the same program number as z/OS, and it's probably a good idea to order them. Here are some examples: 5610-A01z/OS Management Facility 5655-M23Ported Tools for z/OS 5655-J51XML Toolkit for z/OS 5655-W4464-bit Java SDK for z/OS 5655-W4331-bit Java SDK for z/OS Do not order the following font products when you order z/OS Version 2: 5648-B33, 5648-E76, 5655-M32. These previously optional products are now part of the base z/OS Version 2. (There are also potentially Asian font product numbers that should not be ordered for z/OS Version 2, but that's not a factor for most readers here.) The full z/OS 2.1 announcement is available here: http://www.ibm.com/common/ssi/rep_ca/2/897/ENUS213-292/ENUS213-292.PDF Some/many of the products you mentioned have different IBM program numbers and are licensed separately. The IBM Software Support Lifecycle Web site is a reasonably good source of IBM program numbers if you need them: http://www.ibm.com/software/support/lifecycle/index_a_z.html If you want more details on a particular IBM program number/product you can look at the applicable IBM announcement letter (and search using the program number if you wish): http://www.ibm.com/common/ssi Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
