Re: Issue with JES SPOOL
Thanks to everyone for the JES2 share. Great knowledge. Regards, Suresh On Thu, Sep 26, 2013 at 3:10 AM, baby eklavya wrote: > Hello everyone , > > > Is there a different way to come out of the below situation other than a > cold start of JES2 > > *$HASP050 JES2 RESOURCE SHORTAGE OF TGS - 100 % UTILIZATION REACHED * > > Recently , we ended up in a situation where nobody could logon to the > system , and when tried to purge the jobs from console ,it didnt work > either . We are currently tuning the JESPARMS and setting up exits to avoid > such issues in future . But i was wondering if there was anything else we > could have done when the issue really happened . > > > Unfortunately , we didnt have spare spool volumes to start and i felt that > JES2 was not accepting any commands at that point of time . Any thoughts ?? > > Thanks in Advance , > Baby > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- *SureshNc* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Work long hours (Was Re: Pissing contest(s))
Lynn, Yep I agree worked with some oriental programs, who slept under their desks..these guys were unbelievably good programmers..the group I worked with wasn't quite that bad, no in a negative sense. Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' > On Sep 26, 2013, at 9:40 AM, Anne & Lynn Wheeler wrote: > > elardus.engelbre...@sita.co.za (Elardus Engelbrecht) writes: >> I have occassionaly done a full night work, especially during >> emergencies like botched installation, upgrade or big changes. > > as undergraduate in the 60s, the univ would shutdown the datacenter from > 8am sat until 8am monday ... and let me have the whole place to myself > ... initially 709/1401 ... and in transition to 360, the 1401 was > replaced by 360/30 ... and then both 709 and 360/30 replaced by 360/67 > (mostly ran as 360/65). after having been up for 48hrs, it was sometimes > difficult to deal with monday classes. > > old post with "Real Programmers" tome > http://www.garlic.com/~lynn/2002e.html#39 > > one of the items: > > Real Programmers never work 9 to 5. If any real programmers are > around at 9am, it's because they were up all night. > > ... snip ... > > mentions getting complaints about tracking mud in halls of ibm san jose > research (from cleats in hiking boots) ... path that I walked to work > turned to mud when it rained. > > slightly different "Real Programmers" version > http://www.garlic.com/~lynn/2001e.html#31 > as bonus, also has "Real Software Engineers". > > past post > http://www.garlic.com/~lynn/94.html#18 > > while the 360/67 mostly ran as 360/65, I did get to play a little with > cp67 on the weekend ... has part of share presentation that I did fall > of '68 ... references some performance measures from having re-written a > lot of the cp67 kernel > http://en.wikipedia.org/wiki/CP/CMS > > The above mentions initial cp67 release May 1968 ... however, three > people from the science center came out last week of jan1968 to install > cp67 at the univ ... and then I was invited to spring 1968 share meeting > in houston for announcement ... I had already started to rewrite a lot > of the code by that time. > > I also took apart os/360 stage2 sysgen and re-arranged order of all the > cards to carefully place datasets and pds members for optimal arm seek > motion (pds member ordering also minimized multi-track pds directory > search) ... getting almost three times throughput improvement for > univ. student job workload. > > -- > virtualization experience starting Jan1968, online at home since Mar1970 > > -- > 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: Issue with JES SPOOL
Thank you very much everyone for the replies .. They are indeed very useful and informative ! Thanks a lot ! On Thu, Sep 26, 2013 at 4:38 PM, nitz-...@gmx.net wrote: > > But in no case did we have to cold start. > I second that. We have a 100% JES2 shortage of one kind or another about > every 3 months. So far I managed to get by without a cold start. > > The problem as I see it is reducing the shortage to the point that a logon > will be possible again. A number of display and purge commands have been > named already, but in my experience the steps are: > > 1. Determine who holds a lot of the resource. In many cases, it is an > active address space, and you want to first get it to stop further writing > to spool or to write its buffers to the spool just cleared, throwing you > back into a 100% shortage. It may be impossible to cancel such an address > space. I know that I used the force command to stop it from further filling > up spool. > > 2. Once you're sure no active address spaces are still writing like crazy, > determine who holds a lot of spool. And then use the commands named before > from the console, without resorting to SDSF. > > 3. Once you manage to get spool usage down to the point that you get into > TSO/SDSF again, you have better chances in saving output and clearing it. > > 4. Finally, prepare for the next shortage: > a) Set alerts for the HASP050 message designed to notify you early enough > so you can still login. > b) Practise purging of output via JES commands without the convenient use > of SDSF. I consider that the biggest challenge, but I never was an operator. > c) Prepare a spare spool data set to add if necessary. My advise is to > keep such a volume in reserve, but never to add it automatically. Be aware > that there are cases when you cannot add a spool volume because it would > require the resource you're short of (I forgot which that was -JOEs?) Once > you're out of your spool shortage after adding the spare, don't forget to > remove the spare, so you have it again for the next shortage. > d) Set up a procedure for spool offload and practise unloading your spool. > Presumably also practise reloading it. > > Barbara > > -- > 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
OT: Bill Gates: Control-Alt-Delete 'was a mistake'
http://news.cnet.com/8301-10805_3-57604752-75/bill-gates-control-alt- delete-was-a-mistake/?part=rss&subj=news&tag=title Yes I know the video is 54 minutes long but in my opinion its worth it. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM's massive bet on Watson - Sep. 19, 2013
http://money.cnn.com/2013/09/19/technology/ibm-watson.pr.fortune/ index.html?section=magazines_fortune -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISV SMF DSECT Layout to something more readable
On 9/25/2013 3:59 AM, Mark Regan wrote: I have a ISV software product that creates SMF records for which they do not publish the SMF record layout in their manuals. All they do is refer you to the DSECT coding in their MAC library and expect you to figure out the record layout from it. Not having a background in a programming language, especially assembler (I can do some SAS, but that's about it), is there a utility that can read a dsect and produce a readable output to work from? Compile this: PRINT ON,GEN IsvMacroName , <-- this is the name of their mapping macro END , Hopefully you'll be able to understand the record layout from the offsets in the listing. Remember, they are in hex, not decimal. -- 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: SPLEVEL SET=2
On 9/26/2013 2:51 AM, Manfred Lotz wrote: Hi all, I've got a very old assembler program which still has a SPLEVEL SET=2 statement at the beginning. I think that these days this is obsolete and should be removed. FWIW, we use this: SPLEVEL SET=6 Specify OS/390 R2 macro format SYSSTATE ARCHLVL=2Program requires z/Architecture SYSSTATE OSREL=ZOSV1R9Program requires z/OS 1.9 and higher -- 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: CA Common Services 14.1 can cause outages
For those not wanting to get the secured message - here is what she posted I have cross reported this on the MVS-OE listserv. We started having abends in anything related to Unix Systems Services a couple of days after we installed CA Common Services Release 14.1. Abends that appeared repeatedly were an abundance of 0C4's in IBM modules IGVRVSM, IGVVSERR, IGVVSTOR & IEAVESAR which could be found in LOGRECS. Be sure you have the Hipers installed that are related to CSA for this product, which did fix the problem (ro59409, ro48287). We had 4 or 5 IPL's before it could be figured out. It didn't show up in our test systems where we had it for a couple of months. It showed up when a project started that kicked off many ABINITIO processes. Unfortunately, we had changes made for Abinitio, TFS installed and CA Common Services Release 14.1 all go in almost simultaneously. -- Mary Byers Lead Systems Programmer II ABCBS -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Byers, Mary K Sent: Thursday, September 26, 2013 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CA Common Services 14.1 can cause outages You have received a secure message from Byers, Mary K entitled, "CA Common Services 14.1 can cause outages". You may view the message (before 10/11/2013) at the following web address: https://securemail.usablecs.com/messenger/msg?x=d-14309134-K4hOWEdk - Delivered with Secure Messenger (TM) http://www.tumbleweed.com Secure Messenger is a trademark of Tumbleweed Communications Corp. -- 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: Setting up NJE
Since there are many steps and many parts to setting this up, you need to create a Checklist that will help you go through the process. Have you reviewed the following SHARE presentation from 2007? http://proceedings.share.org/client_files/SHARE_in_Denver/S2346GT115930.pdf Have you done the steps needed to setup NJE JES2 over TCPIP on z/OS Guests running on z/VM This I am not sure about Did you setup your z/VM system to allow NJE over TCPIP for JES2 You will find with most lists, unless there is an I DID THIS and I GOT THIS type of question, it is not readily or easily answered. If you can provide display command output, setup process (what did you do to set this up), there might be better answers or responses. Just telling us you have XMITTER and no transmission just means it is not setup correctly. Your connections are not active and waiting for work. Never provide info like I DID IT THIS WAY, instead cut and paste the complete control cards or displays. If you do a PING, show us the ping output. Did you start the server? What were the messages at startup? For example, if you defined SOCKD0D2 then did you do the jes2 command $sn,SOCKET=SOCKD0D2 If so what was JES2 response? Provide the complete $HASP message If you are defined on 60 and 62, did you do a $DNODE(60,62),NAME,STATUS What was the $HASP messages Did you do a $snetsrv What was the $HASP message And there are more things identified in the SHARE PRESENTATION Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Wednesday, September 25, 2013 8:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Setting up NJE Hello All, Thanks for responding. Here my statement looks little confusing. >From the LPAR99, The SOCKET statement has NETSRV(0) for LPAR77 with its IP address. Also, LPAR99 has NETSRV(0) with its LOCAL >From the LPAR77, The SOCKET statment has NETSRV(1) for LPAR77 with its IP ADDRESS as LOCAL. The LPAR99 has again NETSRV(0) with its IP address. Here I would like to understand if NETSRV(Suffix values like 0 or 1) makes any differences ?? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CA Common Services 14.1 can cause outages
You have received a secure message from Byers, Mary K entitled, "CA Common Services 14.1 can cause outages". You may view the message (before 10/11/2013) at the following web address: https://securemail.usablecs.com/messenger/msg?x=d-14309134-K4hOWEdk - Delivered with Secure Messenger (TM) http://www.tumbleweed.com Secure Messenger is a trademark of Tumbleweed Communications Corp. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for help with an obscure C integer problem
I was the OP. I'm going to take the liberty of replying here. I coded around it.
This is the problem for me with IBM fixes. Not complaining, just stating a
fact: I could not have waited this long for a fix.
It's too bad IBM does not have some more-established process whereby one could
report a bug
a. Without the "burden of proof" required for a PMR.
b. In return, without any expectation of a timely fix.
Just the way one of your co-workers might say "you now, I was running your code
the other day, and here's something you might want to take a look at ..."
Would work for me anyway.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Bernd Oppolzer
Sent: Thursday, September 26, 2013 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fwd: Re: Looking for help with an obscure C integer problem
Hello,
I told you at end of July that an IBM employee took this problem and sent it to
IBM maintenance, although there was no formal requirement to do so, only the
discussions in this list. Thanks from this place for this help.
In the meantime there is a solution, and I was asked if someone needs an
Interim fix (a PTF, I think), which could be made available, but only for z/OS
1.12 and 1.13, as far as I understood.
If you need such a fix, would you please respond me offline?
Thank you, kind regards
Bernd
Original-Nachricht
Betreff:Re: Looking for help with an obscure C integer problem
Datum: Sat, 27 Jul 2013 21:11:38 +0200
Von:Bernd Oppolzer
An: IBM Mainframe Discussion List
Hello,
I would like to tell you about the steps needed until I discovered the HGPR
option as the source of the problem.
First I tried the function below, but the value in lwert was constant.
The compiler simply optimized all the computation away and simply printed the
result, so there was no computation at all, and no error, so I had to read the
value for lwert from a file, so that the compiler could not throw away the
computation.
Then, when I changed this, there was again no error. But, as I remarked, the
compiler used no LG etc. instructions. So there must be some different options.
I had different ARCH and TUNE settings, so I changed my options to the same
settings that Charles had, but that didn't change anything.
I got no LG etc. instructions, anyway - and computation still was right,
without the error.
Then I discovered the HGPR option ...
Now for informing IBM:
I'm a freelancer actually working at a big company. I will try to ask the
people which are responsible for compiler installation etc., but I can imagine,
what they will tell me:
"do we use this option? do we have a problem with this error?
No? So we will take no action on this ..."
So I think we will not do anything about this, sorry.
Sorry; I'm not involved in the decision processes there; if I were, I would act
different.
If some IBM people hanging around here read this:
wouldn't it be possible that they take action based on my description of the
error? I would appreciate it, and the C/C++ community here, too, I believe.
Kind regards
Bernd
Am 27.07.2013 18:07, schrieb Bernd Oppolzer:
> I was able to reproduce the problem with a little test program:
>
>
> #include
> #include
>
> static void longtest (long long lwert) {
>int test;
>test = lwert & 0xLL;
>if (test != 0)
>{
> printf ("lwert right = %x\n", test);
>}
>else
>{
> test = lwert >> 32;
> printf ("lwert left = %x\n", test);
>}
> }
>
> int main (void)
> {
>long long lwert;
>int l1;
>int l2;
>int *p;
>char zeile [85];
>fgets (zeile, 80, stdin);
>l1 = atoi (zeile);
>fgets (zeile, 80, stdin);
>l2 = atoi (zeile);
>lwert = l1;
>lwert <<= 32;
>lwert += l2;
>p = (int *) (&lwert);
>printf ("long long first part = %x\n", *p);
>printf ("long long second part = %x\n", *(p + 1));
>longtest (lwert);
> }
>
>
> this was compiled using z/OS XL C version 1.11.
>
> The error only showed up when using the compile option HGPR, that is,
> when the compiler used the G-instructions, like SRAG etc.
>
> results with HGPR:
>
> long long first part = 8000
> long long second part = 0
> lwert left = 0
>
> results without HGPR:
>
> long long first part = 8000
> long long second part = 0
> lwert left = 8000
>
> this can be confirmed by looking at the ASSEMBLER code generated in
> both cases:
>
> with HGPR:
>
> * longtest (lwert);
> LG r0,lwert(,r13,304)
> ST r0,lwert%2=>1(,r13,316)
> TEST LONG LONG:
> SRAG r0,r0,32
> ST r0,lwert%2=>1(,r13,312)
> + LG r0,lwert%2=>1(,r13,312)
> + LTR r0,r0
> + BE @1L6
> + LA r1,+CONSTANT_AREA(,r2,55)
> + ST r0,#MX_TEMP1(,r13,228)
> + LGF r15,=V(PRINTF)(,r3,362)
> + ST r1,#MX_TE
Re: HMIGRATE in parallel
Great ideas. Please open Marketing Requirements for the suggestions so that they can be officially tracked and managed. Thanks, Glenn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Quote on Slashdot.org
John McKown wrote: >"Ada is PL/I trying to be Smalltalk. -- Codoso diBlini" >And a few other amusing quotes. http://www.cs.ucsb.edu/~ravenben/humor/csfunny Amusing indeed. Thanks. ;-) "A program is never less than 90% complete, and never more than 95% complete. -- Terry Baker " I'm confused by this one. Are bugs+documentation included in those numbers or not? ;-0 "And thou shalt make loops . . .-- Exodous 24:6" should be -- Exodus 26:4 >To lighten up the atmosphere from some of the recent OT messages. Indeed. It is high time. In a few nanoseconds it will be Friday! ;-) >I have _not_ lost my mind! It is backed up on a flash drive somewhere. Tsk. Tsk. Tsk. Format it! 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: Old Info-zip program
Hm, I only have a USS version of zip and unzip to be run in a shell, or if in batch then for instance in BPXBATCH. Here a command line example: unzip test.zip unpacks all files in test.zip into the current directory unzip -d out test.zip unpacks all files in test.zip into directory out which will be created if not existing If you want to access an MVS file the syntax is like this: "//'myhlq.some.file'". unzip is able to read an MVS data set.so in a shell you could do this: unzip -d out "//'myhlq.test.zip'" -- Manfred -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: R744STRC SMF Field
Hi, yes it was the right field and column. I have made a mistake in calculating the value. 96 is right. RMF does add up some SMF records which are in a short period of time. It is too complicated to describe hearer but now it works for me. Thank you for your help. Cheers Uwe Am 23.09.2013 um 00:57 schrieb Charles Mills : > Are you sure that's the right sub-type? I don't know this SMF record type at > all but CB3EBAB7 4D1D6525 seems a little implausible as a " Structure > version number." (However, the first 16 and the next two byte values look > right.) > > I can't convert floating point in my head but is not 42 hex = 66 decimal = > an exponent of 66 - 64 = 2? FWIW, the field at +34 does appear to be the sum > of the next three fields (two of which are zero). > > HTH, > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Uwe Oswald > Sent: Saturday, September 21, 2013 9:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: R744STRC SMF Field > > Hi @all, > > hope someone can help me. I got stuck on a problem with a SMF field. Have > someone ever tried to analyze a SMF74 ST 4 (Coupling Facility Activity) > record. I do not see the value 5425 as a long floating point value in the > record in any field. Can someone point me into the right direction? > > HELP. > > Thx > Uwe > > Here is the RMF CF Report output > > * TOP OF DATA > ** > C O U P L I N G F A C I L I T Y A > C > > z/OS V1R13 SYSPLEX PRDPLEX DATE 09/14/2013 > RPT VERSION V1R13 RMF TIME 05.59.38 > > > > - > COUPLING FACILITY NAME = RZAC1P1 > TOTAL SAMPLES(AVG) = 897 (MAX) = 898 (MIN) = 896 > > > - > COUPLING FACILITY USAGE > SUMMA > > > - > STRUCTURE SUMMARY > > > - > > % OF % OF% > OF > STRUCTURE ALLOC CF #ALL > CF > TYPE NAME STATUS CHGSIZESTOR REQREQ > UTIL > > LIST DB2D_SCA ACTIVE 33M 0.2 5425 0.5 > 0.4 > > The bold marked value is R744STRC from my point of view. > > In ERBSHOW I see this block. > > #13: +: C4C2F2C4 6DE2C3C1 40404040 40404040 *DB2D_SCA* >+0010: CB3EBAB7 4D1D6525 0180 9651 *ô ¬¼( Á Øoé* >+0020: 0082 * b* >+0030: 4260 *â- * >+0040: 4260 *â- * >+0050: EA15 032E1347 * ²å* >+0060: ** >+0070: ** >+0080: ** >+0090: ** >+00A0: ** > > > SMF Field: > Offset > D H > 52 34 R744STRC 8 l_float The total number of IXLLIST, IXLCACHE, or IXLLOCK > requests made. This field will not necessarily equal the sum > > -- > 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
Quote on Slashdot.org
"Ada is PL/I trying to be Smalltalk. -- Codoso diBlini And a few other amusing quotes. http://www.cs.ucsb.edu/~ravenben/humor/csfunny To lighten up the atmosphere from some of the recent OT messages. -- I have _not_ lost my mind! It is backed up on a flash drive somewhere. 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: Old Info-zip program
On 21 August 2013 20:39, Barry Merrill wrote: > It's an easy JCL exercise to conduct an experiment to confirm what happens: > > TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was > truncated. > > I copied a 105472 byte valid tersed file into a > DISP=(,CATLG,CATLG),SPACE=(TRK,(1)). > The original untersed to 360,480 bytes, while the truncated file > untersed to only 48152, and there was no message nor warning that the input > file was short. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Manfred Lotz Sent: Thursday, September 26, 2013 7:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Old Info-zip program < I know the Info-zip program is very old, year 2000, but I need a FREE compression program that checks the consistency of the compressed file when it is uncompressed. info-zip works fine on one of our systems (z/OS 1.13 USS). There is another possibility to zip a file. You could use jar, the Java archive tool. A JAR file is just a zip file. < I was using TRSMAIN, but I found out the hard way that a tersed file can be truncated and TRSMAIN doesn't issue an error message. Ooops. This I would classify as a bug. Did you open a PMR? -- Manfred -- 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
Fwd: Re: Looking for help with an obscure C integer problem
Hello,
I told you at end of July that an IBM employee took this problem and
sent it to IBM maintenance, although there was no formal requirement
to do so, only the discussions in this list. Thanks from this place for
this help.
In the meantime there is a solution, and I was asked if someone needs an
Interim fix (a PTF, I think), which could be made available, but only for
z/OS 1.12 and 1.13, as far as I understood.
If you need such a fix, would you please respond me offline?
Thank you, kind regards
Bernd
Original-Nachricht
Betreff:Re: Looking for help with an obscure C integer problem
Datum: Sat, 27 Jul 2013 21:11:38 +0200
Von:Bernd Oppolzer
An: IBM Mainframe Discussion List
Hello,
I would like to tell you about the steps needed until I discovered the
HGPR option as the source of the problem.
First I tried the function below, but the value in lwert was constant.
The compiler simply optimized all the computation away and simply
printed the result, so there was no computation at all, and no error,
so I had to read the value for lwert from a file, so that the compiler
could not throw away the computation.
Then, when I changed this, there was again no error. But, as I remarked,
the compiler used no LG etc. instructions. So there must be some
different options.
I had different ARCH and TUNE settings, so I changed my options to
the same settings that Charles had, but that didn't change anything.
I got no LG etc. instructions, anyway - and computation still was right,
without the error.
Then I discovered the HGPR option ...
Now for informing IBM:
I'm a freelancer actually working at a big company. I will try to ask
the people which are responsible for compiler installation etc.,
but I can imagine, what they will tell me:
"do we use this option? do we have a problem with this error?
No? So we will take no action on this ..."
So I think we will not do anything about this, sorry.
Sorry; I'm not involved in the decision processes there; if I were,
I would act different.
If some IBM people hanging around here read this:
wouldn't it be possible that they take action based on
my description of the error? I would appreciate it,
and the C/C++ community here, too, I believe.
Kind regards
Bernd
Am 27.07.2013 18:07, schrieb Bernd Oppolzer:
I was able to reproduce the problem with a little test program:
#include
#include
static void longtest (long long lwert)
{
int test;
test = lwert & 0xLL;
if (test != 0)
{
printf ("lwert right = %x\n", test);
}
else
{
test = lwert >> 32;
printf ("lwert left = %x\n", test);
}
}
int main (void)
{
long long lwert;
int l1;
int l2;
int *p;
char zeile [85];
fgets (zeile, 80, stdin);
l1 = atoi (zeile);
fgets (zeile, 80, stdin);
l2 = atoi (zeile);
lwert = l1;
lwert <<= 32;
lwert += l2;
p = (int *) (&lwert);
printf ("long long first part = %x\n", *p);
printf ("long long second part = %x\n", *(p + 1));
longtest (lwert);
}
this was compiled using z/OS XL C version 1.11.
The error only showed up when using the compile option HGPR,
that is, when the compiler used the G-instructions, like SRAG etc.
results with HGPR:
long long first part = 8000
long long second part = 0
lwert left = 0
results without HGPR:
long long first part = 8000
long long second part = 0
lwert left = 8000
this can be confirmed by looking at the ASSEMBLER code generated in
both cases:
with HGPR:
* longtest (lwert);
LG r0,lwert(,r13,304)
ST r0,lwert%2=>1(,r13,316)
TEST LONG LONG:
SRAG r0,r0,32
ST r0,lwert%2=>1(,r13,312)
+ LG r0,lwert%2=>1(,r13,312)
+ LTR r0,r0
+ BE @1L6
+ LA r1,+CONSTANT_AREA(,r2,55)
+ ST r0,#MX_TEMP1(,r13,228)
+ LGF r15,=V(PRINTF)(,r3,362)
+ ST r1,#MX_TEMP1(,r13,224)
+ LA r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS 0H
+ LA r0,+CONSTANT_AREA(,r2,73)
+ ST r0,#MX_TEMP1(,r13,224)
+ LGHI r0,H'0'
+ LGF r15,=V(PRINTF)(,r3,362)
+ LA r1,#MX_TEMP1(,r13,224)
+ ST r0,#MX_TEMP1(,r13,228)
+ BASR r14,r15
+@1L7 DS 0H
without HGPR:
* longtest (lwert);
Lr4,(,r13,240)
TEST LONG LONG:
ICM r0,b'',(r13,244
+ BE @1L6
+ LA r1,+CONSTANT_AREA(,r2,55)
+ ST r0,#MX_TEMP1(,r13,228)
+ Lr15,=V(PRINTF)(,r3,302)
+ ST r1,#MX_TEMP1(,r13,224)
+ LA r1,#MX_TEMP1(,r13,224)
+ BASR r14,r15
+ B@1L7
+@1L6 DS 0H
+ LA r0,+CONSTANT_AREA(,r2,73)
+ LA r5,0
+ ST r0,#MX_TEMP1(,r13,224)
+ SRDA r4,32
+ L
Re: Work long hours (Was Re: Pissing contest(s))
elardus.engelbre...@sita.co.za (Elardus Engelbrecht) writes: > I have occassionaly done a full night work, especially during > emergencies like botched installation, upgrade or big changes. as undergraduate in the 60s, the univ would shutdown the datacenter from 8am sat until 8am monday ... and let me have the whole place to myself ... initially 709/1401 ... and in transition to 360, the 1401 was replaced by 360/30 ... and then both 709 and 360/30 replaced by 360/67 (mostly ran as 360/65). after having been up for 48hrs, it was sometimes difficult to deal with monday classes. old post with "Real Programmers" tome http://www.garlic.com/~lynn/2002e.html#39 one of the items: Real Programmers never work 9 to 5. If any real programmers are around at 9am, it's because they were up all night. ... snip ... mentions getting complaints about tracking mud in halls of ibm san jose research (from cleats in hiking boots) ... path that I walked to work turned to mud when it rained. slightly different "Real Programmers" version http://www.garlic.com/~lynn/2001e.html#31 as bonus, also has "Real Software Engineers". past post http://www.garlic.com/~lynn/94.html#18 while the 360/67 mostly ran as 360/65, I did get to play a little with cp67 on the weekend ... has part of share presentation that I did fall of '68 ... references some performance measures from having re-written a lot of the cp67 kernel http://en.wikipedia.org/wiki/CP/CMS The above mentions initial cp67 release May 1968 ... however, three people from the science center came out last week of jan1968 to install cp67 at the univ ... and then I was invited to spring 1968 share meeting in houston for announcement ... I had already started to rewrite a lot of the code by that time. I also took apart os/360 stage2 sysgen and re-arranged order of all the cards to carefully place datasets and pds members for optimal arm seek motion (pds member ordering also minimized multi-track pds directory search) ... getting almost three times throughput improvement for univ. student job workload. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old Info-zip program
Here is the JCL and error messages. The zipped files does exist, I can see it and browse it under ISPF 3.4. BROWSELDARP1.ZIPPED Line Col 001 132 Command ===> Scroll ===> CSR *** Top of Data ** &.ã<.äli.xL...t...<à ê&..|íè&íè..å..ð._e..üì]l.>C..ஶ]-..h.O.c`.f.ñ$.ÜaÒê«íI. //STEP1EXEC PGM=UNZIP, // PARM='''LDARP1.ZIPPED'' ''LDARP1.UNZIP'' *' //STEPLIB DD DSN=LDA.XMITIP.LOAD,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSOUT DD SYSOUT=* error: cannot open zipfile [ 'LDARP1.ZIPPED' ] unzip: cannot find either 'LDARP1.ZIPPED' or 'LDARP1.ZIPPED'.zip. --- manfred.l...@googlemail.com wrote: From: Manfred Lotz To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Old Info-zip program Date: Thu, 26 Sep 2013 08:12:00 -0500 < The truncation occurred in the sftp transmission step(s). I was able to get the zip part of Infozip to work, but not the unzip. Would you be willing < to share you Infozip zip/unzip programs? I would be willing. But what I have is just the software from the download page. Let us first investigate what went wrong. When you try to use unzip what error messages do you get? -- Manfred -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old Info-zip program
The transmission was interrupted from the sending side. The sending side uses Outbound to send the mainframe file to a server. Then a process is kicked off on the server by Outbound. The process started by Outbound is not monitored, and in this case the transmission ended abnormally. No way to know this unless I compared the byte count originally displayed by Outbound when it sent the file to the server against the byte count that TRSMAIN displays after the unterse. --- elardus.engelbre...@sita.co.za wrote: From: Elardus Engelbrecht To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Old Info-zip program Date: Thu, 26 Sep 2013 07:59:57 -0500 Richard Pinion wrote: >The truncation occurred in the sftp transmission step(s). Ok. Show us your dataset/files atrributes and your SFTP attempt and messages. I believe you need some FTP statements to prevent truncations/incorrect translations. 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 _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old Info-zip program
< The truncation occurred in the sftp transmission step(s). I was able to get the zip part of Infozip to work, but not the unzip. Would you be willing < to share you Infozip zip/unzip programs? I would be willing. But what I have is just the software from the download page. Let us first investigate what went wrong. When you try to use unzip what error messages do you get? -- Manfred -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Setting up NJE
Hello All, When I tried with /*route xeq lpar99 from lpar77 its again in xmitter status. To check if the DNS name is getting resolved but it wasn't doing anything(I just checked from ISPF.6 with ping lpar99 and I got as unknown host) On Thu, Sep 26, 2013 at 9:24 AM, mf db wrote: > Hello All, > > Thanks for responding. > > Here my statement looks little confusing. > > From the LPAR99, > The SOCKET statement has NETSRV(0) for LPAR77 with its IP address. > Also, LPAR99 has NETSRV(0) with its LOCAL > > From the LPAR77, > The SOCKET statment has NETSRV(1) for LPAR77 with its IP ADDRESS as LOCAL. > The LPAR99 has again NETSRV(0) with its IP address. > > Here I would like to understand if NETSRV(Suffix values like 0 or 1) makes > any differences ?? > > > > > On Thu, Sep 26, 2013 at 1:03 AM, Lizette Koehler > wrote: > >> Correct, I was only asking if the OP was using one or the other. I can >> see >> how it is confusing with my last statement. >> >> However, if the OP cannot PING the TCPIP connection, then it is not >> established. >> >> Validation of the connection in TCPIP and the JES2 definitions needs to be >> done to determine if the connection is good. >> >> Lizette >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Wissink, Brad [ITSYS] >> Sent: Wednesday, September 25, 2013 11:47 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Setting up NJE >> >> I have NJE setup between two Lars using TCP/IP. And I have no VTAM >> definitions. >> >> Brad Wissink >> Sent from my Verizon Wireless 4G LTE DROID >> >> >> mf db wrote: >> >> Lizette, >> >> I am using TCPIP, VTAM definitions are not done, but I have made those NJE >> definition on JES2PARMS and related NETSRV1 address spaces have been >> defined. >> >> Could you please point me the VTAM definition if it is required for NJE >> over >> TCPIP ? >> >> >> On Wed, Sep 25, 2013 at 12:45 PM, Lizette Koehler >> wrote: >> >> > I forgot - >> > >> > Are you using SNA, TCPIP, or other for JES2 NJE Connections? >> > >> > JES2 alone cannot connect without a VTAM (TCPIP or SNA) connection. >> > Check that your VTAM definitions are in place and active. >> > >> > Lizette >> > >> > >> > -Original Message- >> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> > On Behalf Of Lizette Koehler >> > Sent: Wednesday, September 25, 2013 12:12 AM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Re: Setting up NJE >> > >> > Cross Posting to IBM Main and JES2 >> > >> > First >> > >> > The JCL card should read /*ROUTE XEQ nodename >> > >> > And I am not sure what your VTAM, JES2 deck, and other parts might be. >> > >> > If you are running use SDSF or MVS Console to do >> > >> > D NET,ID=vtamapplid,E >> > >> > $DNODEnodename >> > >> > >> > Please look up the commands as you will need to know how to do this. >> > >> > This is a good overview of SDSF (If you use that) >> > http://www.mabu.org/sdsf_overview.pdf >> > >> > >> > XMITTER typically means your nodes are not connected. But that is >> > unique to your shop. >> > >> > Also, you can do internet searches on your issues and see if you can >> > work them out. Use phrases like >> > >> > IBM JES2 NJE >> > >> > For other documentation. >> > >> > Lizette >> > >> > >> > -Original Message- >> > From: JES2 discussion group [mailto:jes...@listserv.vt.edu] On Behalf >> > Of mf db >> > Sent: Tuesday, September 24, 2013 9:28 PM >> > To: jes...@listserv.vt.edu >> > Subject: Re: Setting up NJE >> > >> > --001a1133eaca44df1304e72daf24 >> > Content-Type: text/plain; charset=ISO-8859-1 >> > >> > Hello All, >> > >> > Cross posted to IBM MAIN and JES2 listserves >> > >> > I submitted a job with a route card /*ROUTE LPAR99 from the >> > LPAR77(Both the LPARS are MVA guest running on Z/VM), But the Job >> > stays in XMITTER status and the Job is not executing on the target >> > LPAR(LPAR99) >> > >> > NETSRV1 is active on both the LPAR(LPAR99 and LPAR77). >> > >> > Z/OS : 1.13 >> > >> > Could someone point me to the right direction. >> > >> > >> > >> > >> > On Wed, Sep 18, 2013 at 10:45 AM, mf db wrote: >> > >> > > Hello, >> > > >> > > Yes, the two MVS guest are coupled with CTC's >> > > >> > > >> > > >> > > >> > > On Wed, Sep 18, 2013 at 2:49 AM, Tom Wasik wrote: >> > > >> > >> It would seem to me that using TCP/IP would be the easiest way to >> > >> make this NJE connection happen (again as long as they are not in >> > >> the >> > same MAS). >> > >> Assuming each MVS image has an IP address that can be accessed >> > >> from the other MVS image, then it is just a matter of defining the >> > >> needed NJE NETSERVs, SOCKETs, and LINEs in JES2. >> > >> If you do not have TCP/IP for some reason, and you are 2 guests on >> > >> the same VM image, you can use virtual CTC adapters in VM to set up >> > >> a BSC connection between the 2 guest images. This is a bit old >> > >> fashion, but it still works and is probably the easiest NJE to set
Re: Old Info-zip program
Richard Pinion wrote: >The truncation occurred in the sftp transmission step(s). Ok. Show us your dataset/files atrributes and your SFTP attempt and messages. I believe you need some FTP statements to prevent truncations/incorrect translations. 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: Old Info-zip program
Richard Pinion wrote: >I was using TRSMAIN, but I found out the hard way that a tersed file can be >truncated and TRSMAIN doesn't issue an error message. Ouch. What version of z/OS and TRSMAIN are you using? What type of datasets or files are you using as input for tersing? AFAIK: I know TRSMAIN is somewhat picky about what it can accepts as input. I smell a possible PMR for you. I just can't believe you're not gettting a message about truncating. Perhaps something is shown in SYSPRINT, but still, at what stage (terse/unterse) do you found your data is truncated? Perhaps that message about truncating was also truncated? ;-) 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: Old Info-zip program
The truncation occurred in the sftp transmission step(s). I was able to get the zip part of Infozip to work, but not the unzip. Would you be willing to share you Infozip zip/unzip programs? --- manfred.l...@googlemail.com wrote: From: Manfred Lotz To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Old Info-zip program Date: Thu, 26 Sep 2013 07:37:24 -0500 < I know the Info-zip program is very old, year 2000, but I need a FREE compression program that checks the consistency of the compressed file when it is uncompressed. info-zip works fine on one of our systems (z/OS 1.13 USS). There is another possibility to zip a file. You could use jar, the Java archive tool. A JAR file is just a zip file. < I was using TRSMAIN, but I found out the hard way that a tersed file can be truncated and TRSMAIN doesn't issue an error message. Ooops. This I would classify as a bug. Did you open a PMR? -- Manfred -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Old Info-zip program
< I know the Info-zip program is very old, year 2000, but I need a FREE compression program that checks the consistency of the compressed file when it is uncompressed. info-zip works fine on one of our systems (z/OS 1.13 USS). There is another possibility to zip a file. You could use jar, the Java archive tool. A JAR file is just a zip file. < I was using TRSMAIN, but I found out the hard way that a tersed file can be truncated and TRSMAIN doesn't issue an error message. Ooops. This I would classify as a bug. Did you open a PMR? -- Manfred -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Old Info-zip program
I know the Info-zip program is very old, year 2000, but I need a FREE compression program that checks the consistency of the compressed file when it is uncompressed. I was using TRSMAIN, but I found out the hard way that a tersed file can be truncated and TRSMAIN doesn't issue an error message. I would prefer not to manually check byte counts on the terse and unterse steps, since I am tersing and untersing dozens of files at a time. Files are tersed on one mainframe, transmitted via sftp from the mainframe to a server, retrieved from that server via sftp, and then untersed on another mainframe. Thanks in advance. _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Work long hours (Was Re: Pissing contest(s))
Elardus, Absolutely, life is short, there also is a balance with work and life Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' > On Sep 26, 2013, at 2:19 AM, Elardus Engelbrecht > wrote: > > I'm moving to a new thread. > > Shmuel Metz (Seymour J.) wrote: > >>> Not only in South Africa, we do 18+ in NYC too, > > I have occassionaly done a full night work, especially during emergencies > like botched installation, upgrade or big changes. > >> One of the things that happens as you get older is that you figure out that >> you are not Superman. Sour you can work 72 hours, but your error rate will >> go way up and you'll have to put in even more time to correct the results of >> your sleep deprivation. A smart boss will order you to take a sleep break. > > Indeed. In a mature Data Centre, such overtime may or may not be frowned on, > but you know there are exceptions and of course changes needed to be done > after hours. > > Shmuel, what you said has been confirmed by an IBM-MAIN member who said that > he is posting while really needing sleep and working too many after hours. > He eventually said that he has gone to sleep. And he is OLD and his health is > not of the very best. > > I'm grateful that I can claim overtime, but that must be pre-approved with > formal change procedures - Excessive overtime is frowned on because of high > error and fatigue rate. In fact - the laws of work conditions have improved > over the years. > > I don't have any confirmed proof, but apparently the Japanese people are > FORCED to have leave to take a break every year. True? False? > > I am sure many of the IBM-MAIN members can relate to loong zz > work zz hours... ;-) > > But if your health is suffering, you need to look at your work conditions. > > Groete / Greetings > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pissing contest(s)
Tarzan, We Irish can out crazy you dude ...lol Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' > On Sep 26, 2013, at 6:53 AM, AbsKerneels > wrote: > > Scott/Kees/Jim/Superman/Tarzan and Elvis, > > It's OK, you can call me anything on any given Wednesday because : > > We do not wet our panties or get "turned up stomach" when we get involved in > any competition.. or call for a referee when we get some pee on our leg while > standing next to "peeing contest" because as Arnie called it.. they teach us, > NOT to be GIRLIE men .. at any stage. > > Interesting article this morning about the "Nazis".. as in the NAZI's are > coming to get us again.. and "the right-wing echo chamber breeds extremism, > intimidates Republican moderates and misleads people into thinking that their > worldview is broadly shared" > > http://www.nytimes.com/2013/09/26/opinion/kristof-suffocating-echo-chamber.html?hp > > Kerneels (aka Tarzan) > > > >> On 9/26/2013 3:41 AM, Richards, Robert B. wrote: >> Kees, >> >> Scott owes you an apology! :-) >> >> I believe he confused you with Kerneels (aka Anton Britz) > > -- > 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: Pissing contest(s)
Robert, Your right, sorry Kees Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' > On Sep 26, 2013, at 5:41 AM, "Richards, Robert B." > wrote: > > Kees, > > Scott owes you an apology! :-) > > I believe he confused you with Kerneels (aka Anton Britz) > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Vernooij, CP - SPLXM > Sent: Thursday, September 26, 2013 2:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Pissing contest(s) > > Scott, > > Possibly because English is not my native language, but I don't see what you > are referring to. > > Kees. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Scott Ford > Sent: Thursday, September 26, 2013 04:00 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Pissing contest(s) > > Kees, > > Everyone is referring to appropriateness > > Scott ford > www.identityforge.com > from my IPAD > > 'Infinite wisdom through infinite means' > > -- > 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: Issue with JES SPOOL
> But in no case did we have to cold start. I second that. We have a 100% JES2 shortage of one kind or another about every 3 months. So far I managed to get by without a cold start. The problem as I see it is reducing the shortage to the point that a logon will be possible again. A number of display and purge commands have been named already, but in my experience the steps are: 1. Determine who holds a lot of the resource. In many cases, it is an active address space, and you want to first get it to stop further writing to spool or to write its buffers to the spool just cleared, throwing you back into a 100% shortage. It may be impossible to cancel such an address space. I know that I used the force command to stop it from further filling up spool. 2. Once you're sure no active address spaces are still writing like crazy, determine who holds a lot of spool. And then use the commands named before from the console, without resorting to SDSF. 3. Once you manage to get spool usage down to the point that you get into TSO/SDSF again, you have better chances in saving output and clearing it. 4. Finally, prepare for the next shortage: a) Set alerts for the HASP050 message designed to notify you early enough so you can still login. b) Practise purging of output via JES commands without the convenient use of SDSF. I consider that the biggest challenge, but I never was an operator. c) Prepare a spare spool data set to add if necessary. My advise is to keep such a volume in reserve, but never to add it automatically. Be aware that there are cases when you cannot add a spool volume because it would require the resource you're short of (I forgot which that was -JOEs?) Once you're out of your spool shortage after adding the spare, don't forget to remove the spare, so you have it again for the next shortage. d) Set up a procedure for spool offload and practise unloading your spool. Presumably also practise reloading it. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pissing contest(s)
Get a life Abe. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISV SMF DSECT Layout to something more readable
Charles, Thanks for the tip about assembling the DSECT macro. I found sample JCL in one of the vendor's product libs and I was able to use it to assemble it. The resulting output showed where each field would fall in the SMF record. So that, along with their supplied field descriptions in the DSECT member helped out. I also found the HLASM manuals and that helped to decipher many of the assembler DS instructions. Now to get my SAS job working again. Thanks, Mark Regan <>< From: Charles Mills To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wednesday, September 25, 2013 9:25 AM Subject: Re: ISV SMF DSECT Layout to something more readable Permit me to respond a little further. Which of these sentences best describes your problem? 1. I look at their "documentation" and it is pretty thin. I can see the individual fields, and each one has a one-sentence (or less) comment, but I don't really grasp the business significance of the data, or the meanings of various "codes." 2. I can read C but I can't read assembler. I look at these macros and don't have a clue what to make of them. 3. I am trying to code up some SAS to format these records. I need the offset of the various fields, but all I have is macro source. Answers: 1. Sorry. You are up the creek. If the vendor won't help you, or some "peer" can't help you informally, then you are out of luck. 2. CDSECT is the answer. 3. You need to assemble the macros. Real simple. Basically find some assembler JCL and code it up as //SYSLIB DD DSN=vendor.mac.library,DISP=SHR //SYSIN DD * MACNAME [the name of the vendor macro] END /* The listing should show the offset of each field in hex. You may need a little more on the macro, something perhaps like MACNAME SUBTYPE=ALL Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Regan Sent: Wednesday, September 25, 2013 3:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ISV SMF DSECT Layout to something more readable I have a ISV software product that creates SMF records for which they do not publish the SMF record layout in their manuals. All they do is refer you to the DSECT coding in their MAC library and expect you to figure out the record layout from it. Not having a background in a programming language, especially assembler (I can do some SAS, but that's about it), is there a utility that can read a dsect and produce a readable output to work from? I have an older SAS program that was coded to produce reports from the vendor's older version of the software, but the newest release we just put on changed the SMF record layout and also increased the record length from 1034 to 3194 bytes in length. Thanks, Mark Regan <>< -- 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: Issue with JES SPOOL
100% TGS utilization does not really needs cold start. You just need to capture those HASPxxx message using some automation products. There are some freewares which can help in reacting those messages. If this particular LPAR is not related to production or development then you can always purge the output using JES2 automatic processor commands... You should understand what really fills your JES, or else try adding Spool volumes or do some more research to understand this problems... On Thu, Sep 26, 2013 at 4:17 PM, Miklos Szigetvari < miklos.szigetv...@isis-papyrus.com> wrote: > My experience is the same, several 100% TGS utilization, but never cold > start. > I think for small shops, without any operator, it is important, to be get > notified if some JES limit over the warning values, Email or SMS > > > On 26.09.2013 12:41, Scott Chapman wrote: > >> Others have given great advice on how to get out of the situation or >> avoid it. But to talk to the cold start question: >> >> For various reasons that we don't need to go into here, we have >> experienced 100% TGS utilization multiple times over the last year on >> multiple JESPlexes. Including times when nobody did anything about it and >> allowed the situation to persist for hours. Bad things can start to happen >> if you leave the spool 100% full for hours. >> >> But in no case did we have to cold start. >> >> In fact, I don't think we've done a cold start on any of our JESplexes in >> years. Hmmm... is there a $D for that tidbit? >> >> Scott >> >> . But , am also interested to know if there is a way i could avoid a cold >>> start of JES2 when the TGS utilization reaches 100 % . In our case , we >>> did >>> not have spare spool volumes to add space dynamically . As we had to do a >>> Cold start of JES2 being the last option , am just trying to understand >>> if >>> i had a different option other than that . >>> >> --**--** >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> > > -- > Kind regards, / Mit freundlichen Grüßen > Miklos Szigetvari > > Research& Development > ISIS Papyrus Europe AG > Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria > T: +43(2236) 27551 333, F: +43(2236)21081 > E-mail: > miklos.szigetvari@isis-**papyrus.com > Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 > Visit our brand new extended Website at www.isis-papyrus.com > --**--**--- > This e-mail is only intended for the recipient and not legally > binding. Unauthorised use, publication, reproduction or > disclosure of the content of this e-mail is not permitted. > This email has been checked for known viruses, but ISIS Papyrus accepts > no responsibility for malicious or inappropriate content. > --**--**--- > > > --**--**-- > 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: Pissing contest(s)
Scott/Kees/Jim/Superman/Tarzan and Elvis, It's OK, you can call me anything on any given Wednesday because : We do not wet our panties or get "turned up stomach" when we get involved in any competition.. or call for a referee when we get some pee on our leg while standing next to "peeing contest" because as Arnie called it.. they teach us, NOT to be GIRLIE men .. at any stage. Interesting article this morning about the "Nazis".. as in the NAZI's are coming to get us again.. and "the right-wing echo chamber breeds extremism, intimidates Republican moderates and misleads people into thinking that their worldview is broadly shared" http://www.nytimes.com/2013/09/26/opinion/kristof-suffocating-echo-chamber.html?hp Kerneels (aka Tarzan) On 9/26/2013 3:41 AM, Richards, Robert B. wrote: Kees, Scott owes you an apology! :-) I believe he confused you with Kerneels (aka Anton Britz) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Issue with JES SPOOL
My experience is the same, several 100% TGS utilization, but never cold start. I think for small shops, without any operator, it is important, to be get notified if some JES limit over the warning values, Email or SMS On 26.09.2013 12:41, Scott Chapman wrote: Others have given great advice on how to get out of the situation or avoid it. But to talk to the cold start question: For various reasons that we don't need to go into here, we have experienced 100% TGS utilization multiple times over the last year on multiple JESPlexes. Including times when nobody did anything about it and allowed the situation to persist for hours. Bad things can start to happen if you leave the spool 100% full for hours. But in no case did we have to cold start. In fact, I don't think we've done a cold start on any of our JESplexes in years. Hmmm... is there a $D for that tidbit? Scott . But , am also interested to know if there is a way i could avoid a cold start of JES2 when the TGS utilization reaches 100 % . In our case , we did not have spare spool volumes to add space dynamically . As we had to do a Cold start of JES2 being the last option , am just trying to understand if i had a different option other than that . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research& Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Issue with JES SPOOL
Others have given great advice on how to get out of the situation or avoid it. But to talk to the cold start question: For various reasons that we don't need to go into here, we have experienced 100% TGS utilization multiple times over the last year on multiple JESPlexes. Including times when nobody did anything about it and allowed the situation to persist for hours. Bad things can start to happen if you leave the spool 100% full for hours. But in no case did we have to cold start. In fact, I don't think we've done a cold start on any of our JESplexes in years. Hmmm... is there a $D for that tidbit? Scott > . But , am also interested to know if there is a way i could avoid a cold >start of JES2 when the TGS utilization reaches 100 % . In our case , we did >not have spare spool volumes to add space dynamically . As we had to do a >Cold start of JES2 being the last option , am just trying to understand if >i had a different option other than that . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Issue with JES SPOOL
I tried this one time. it had to match the spool name prefix. /s/ tuco bonno; Graduate, College of Conflict Management; University of SouthEast Asia; "I partied on the Ho Chi Minh Trail - tiến lên !! " > extracted from original post: The $S SPOOL command has the ability to allocate a new space $sspl(spool7),space=(cyl,100) $HASP893 VOLUME(SPOOL7) STATUS=INACTIVE,COMMAND=(START) $HASP646 1. PERCENT SPOOL UTILIZATION $HASP423 SPOOL7 IS BEING FORMATTED $HASP630 VOLUME SPOOL7 ACTIVE 0 PERCENT UTILIZATION JES2 starts spool volume SPOOL7. If SPOOL7 is a new volume, a 100 cylinder sized data set is allocated. However, if SPOOL7 is already defined to JES2, the command fails and the HASP003 error message is issued. Now, what I do not know is if the spool volume name being used has to match the SPOOL Name prefix. Maybe someone can clarify that. Because if you are in a 100% TGS condition, can you just add a spool volume without it matching the spool volume names? That would allow for any empty spare volume being used. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Issue with JES SPOOL
another command that I have found very useful is this one: $djq,spool=(percent>1) and then proceed accordingly to w/ $coj or $poj commands /s/ tuco bonno; Graduate, College of Conflict Management; University of SouthEast Asia; "I partied on the Ho Chi Minh Trail - tiến lên !! " -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of baby eklavya Sent: Wednesday, 25 September, 2013 07:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Issue with JES SPOOL Hello everyone , Is there a different way to come out of the below situation other than a cold start of JES2 *$HASP050 JES2 RESOURCE SHORTAGE OF TGS - 100 % UTILIZATION REACHED * Recently , we ended up in a situation where nobody could logon to the system , and when tried to purge the jobs from console ,it didnt work either . We are currently tuning the JESPARMS and setting up exits to avoid such issues in future . But i was wondering if there was anything else we could have done when the issue really happened . Unfortunately , we didnt have spare spool volumes to start and i felt that JES2 was not accepting any commands at that point of time . Any thoughts ?? Thanks in Advance , Baby -- 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
SPLEVEL SET=2
Hi all, I've got a very old assembler program which still has a SPLEVEL SET=2 statement at the beginning. I think that these days this is obsolete and should be removed. As I'm not sure if removing this could break anything what could I check (besides testing the program itself) in order to make sure all is fine after removing SPLEVEL? The only idea I had was to assembly the source one time using SPLEVEL SET=2 and the next time using SPLEVEL SET=6. Then comparing the assembler listings to see if there is a difference. Any comments appreciated. -- Manfred -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pissing contest(s)
Kees, Scott owes you an apology! :-) I believe he confused you with Kerneels (aka Anton Britz) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Thursday, September 26, 2013 2:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pissing contest(s) Scott, Possibly because English is not my native language, but I don't see what you are referring to. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Thursday, September 26, 2013 04:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Pissing contest(s) Kees, Everyone is referring to appropriateness Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFDSS to move multi volume SMS managed datasets.
So a 80% full mod 54 in 2*80 minutes, let alone a couple of them. Then you will notice the difference, which I mentioned 3 hours i.s.o. 1.5 hours. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Thursday, September 26, 2013 09:12 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using DFDSS to move multi volume SMS managed datasets. A 60% full Mod 9 to VTAPE in about 10 minutes and back in about 10 more minutes. Helps if you can leave it DISABLED NEW for a week or two before cleaning up the remaining datasets. On Thu, Sep 26, 2013 at 1:45 AM, Vernooij, CP - SPLXM wrote: > All datasets from a 3390-54 in minutes? > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mike Schwab > Sent: Wednesday, September 25, 2013 18:34 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Using DFDSS to move multi volume SMS managed datasets. > > When you Migrate by VOLUME, it does a recall of all datasets within a > few minutes. > When you migrate by DSN, it does not recall the dataset until requested. > > On Wed, Sep 25, 2013 at 8:44 AM, Jon Perryman > wrote: >> The drawback to HSM migrate is that the datasets are migrated until > the next use. If the use of any of these datasets can't tolerate the > recall delay, then you will need to ensure it get's recalled before > that time. >> >> Jon Perryman. >> >> >> >>> >>> From: Mike Schwab >>> >>> >>>http://pic.dhe.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm. >>>z >>>os.r11.arcf000/s6085b.htm >>>MIGRATE VOLUME(SG1001) >>>MIGRATE VOLUME(SG2003 MIGRATE(0)) >>>MIGRATE VOLUME(SG1002) DAYS(0) >>> >>>On Wed, Sep 25, 2013 at 7:30 AM, Jim McAlpine >>> > wrote: Is that a DFHSM command, if so I'm not familiar with that, I've always used DFDSS. >>> >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO >> IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in A
Re: Using DFDSS to move multi volume SMS managed datasets.
A 60% full Mod 9 to VTAPE in about 10 minutes and back in about 10 more minutes. Helps if you can leave it DISABLED NEW for a week or two before cleaning up the remaining datasets. On Thu, Sep 26, 2013 at 1:45 AM, Vernooij, CP - SPLXM wrote: > All datasets from a 3390-54 in minutes? > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Mike Schwab > Sent: Wednesday, September 25, 2013 18:34 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Using DFDSS to move multi volume SMS managed datasets. > > When you Migrate by VOLUME, it does a recall of all datasets within a > few minutes. > When you migrate by DSN, it does not recall the dataset until requested. > > On Wed, Sep 25, 2013 at 8:44 AM, Jon Perryman > wrote: >> The drawback to HSM migrate is that the datasets are migrated until > the next use. If the use of any of these datasets can't tolerate the > recall delay, then you will need to ensure it get's recalled before that > time. >> >> Jon Perryman. >> >> >> >>> >>> From: Mike Schwab >>> >>> >>>http://pic.dhe.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.z >>>os.r11.arcf000/s6085b.htm >>>MIGRATE VOLUME(SG1001) >>>MIGRATE VOLUME(SG2003 MIGRATE(0)) >>>MIGRATE VOLUME(SG1002) DAYS(0) >>> >>>On Wed, Sep 25, 2013 at 7:30 AM, Jim McAlpine > wrote: Is that a DFHSM command, if so I'm not familiar with that, I've always used DFDSS. >>> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain confidential > and privileged material intended for the addressee only. If you are not the > addressee, you are notified that no part of the e-mail or any attachment may > be disclosed, copied or distributed, and that any other action related to > this e-mail or attachment is strictly prohibited, and may be unlawful. If you > have received this e-mail by error, please notify the sender immediately by > return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission of > this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
