20GB in 1980 vs. 32GB in 2010
http://cheatedbylife.com/2010/03/20/20gb-in-1980-vs-32gb-in-2010/ I remember the arrival of the newfangled 3380 at the data center I worked at in the early 80's. http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3380.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RC=4093 from TSO ALLOC in compiled REXX
I'm staring myself blind on a silly problem that I've created for myself. Here is a very advanced REXX program: /* rexx */ address TSO "ALLOC F(FILE1) NEW TRACKS SPACE(1) RECFM(F B) LRECL(80) REUSE" exit RC If I execute it using the TSO EXEC command it gives RC=0 as expected,but if I compile the program and run it from the load library, it gives RC=4093! What's the secret? Staffan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 20GB in 1980 vs. 32GB in 2010
>I remember the arrival of the newfangled 3380 at the data center I worked at >in the early 80's. I remember it well, too. They were considered way too expensive to use for paging. As a matter of fact, we were still paging on 3330's, because 3350's were also considered too expensive. That changed! The media was starting to fail on a regular basis, where we were losing Production Online due to problems with page-ins. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RC=4093 from TSO ALLOC in compiled REXX
Could it have something to do with Prefix processing; where it's successful when run in foreground because a Prefix is added to the filename, but not in background because without the Prefix, you end up with an invalid dsn??? Just a guess. All the best, Scott T. Harder Mainframe Services, Inc. Naples, FL > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Staffan Tylen > Sent: Sunday, March 21, 2010 11:11 AM > To: IBM-MAIN@bama.ua.edu > Subject: RC=4093 from TSO ALLOC in compiled REXX > > I'm staring myself blind on a silly problem that I've created for myself. > Here is a very advanced REXX program: > > /* rexx */ > address TSO > "ALLOC F(FILE1) NEW TRACKS SPACE(1) RECFM(F B) LRECL(80) REUSE" > exit RC > > If I execute it using the TSO EXEC command it gives RC=0 as expected,but > if > I compile the program and run it from the load library, it gives RC=4093! > What's the secret? > > Staffan > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Ask the Experts "Shoot-Out"
> For those present in Seattle for the very successful Session 2007: Ask > the Experts & MVS Program Closing, there was some disagreement about > whether V XCF,sys,OFF,REIPL would honor the AUTOIPL MVS settings in > DIAGxx or always re-IPL with the last settings used. > > Empirical evidence being the best kind, I ran the following experiment. > > I looked in my DIAGxx member and found this: > > AutoIpl SaDmp(8211,SNSYSC ) Mvs(LAST) > > Issuing D DIAG from the console, I saw this: > > AUTOIPL SADMP(8211,SNSYSC ) MVS(8110,8100B2 ) > > I changed, my DIAGxx member to: > > AutoIpl SaDmp(8211,SNSYSC ) Mvs(8111,8100B2 ) > > then issued the following command to dynamically effect the change: > > T DIAG=xx > > and proved it was there by issuing: > > D DIAG > > which returned (among other things): > > AUTOIPL SADMP(8211,SNSYSC ) MVS(8111,8100B2 ) > > I then issued: > > V XCF,sys,OFF,REIPL > > and the re-IPL failed. (I guess 8111 is not an IPLable volume). The > error was: > > Central processor (CP) 0 in partition MVSA0, entered disabled wait state. > The disabled wait program status word (PSW) is 000a000f. > Central storage bytes 0-7 are: 000a000f. > > So there you have it. V XCF,sys,OFF,REIPL *does* use the AUTOIPL DIAGxx > settings! Well, of course it does. The purpose of the DUMP and REIPL options of V XCF,sys,OFF,etc. is simply to set the 0A2 wait state reason code to a value which drives the appropriate AutoIPL actions as defined in the WSAT (Wait State Action Table). See MVS Planning: Operationsfor a description of the WSAT. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: XMIT Manager
This did the trick. Thanks, Chuck! Allthe best, Scott > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Chuck Arney > Sent: Wednesday, March 17, 2010 5:29 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: XMIT Manager > > Under Win7 you can setup and run a WinXP Virtual Machine. A free XP > system image is available for download from Microsoft to run under Win7. > You should be able to install and run old software in the XP VM. I've > had to do that with a number of packages. It's a bit slow starting up > the VM but runs fine after that. > > Chuck Arney > illustro Systems International, LLC > http://www.illustro.com > Internet-enable your applications with z/Ware V2 > Voice: 214-800-8900 X#5562 > -- > This e-mail is private and may be confidential and is for the intended > recipient only. If misdirected, please notify us by telephone and > confirm that it has been deleted from your system and any copies > destroyed. If you are not the intended recipient you are strictly > prohibited from using, printing, copying, distributing or disseminating > this e-mail or any information contained in it. > > We use reasonable measures to virus scan all E-mails leaving illustro > but no warranty is given that this E-mail and any attachments are virus > free. You should ensure you have adequate measures in place for your own > virus checking. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Scott T. Harder > Sent: Wednesday, March 17, 2010 4:04 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: XMIT Manager > > Tried that on the setup.exe file, but still get this in a pop-up when I > try > to run it: > > "The version of this file is not compatible with the version of Windows > you > are running. Check your computer's system information to see whether > you > need an x86 (32-bit) or x64 (64-bit) version of the program, then > contact > the software publisher." > > Just for grins, I also tried checking "run as Administrator" on > setup.exe > Properties under Compatibility, but got the same thing. > > I am running Windows-7 64-bit, but other 32 bit software installs fine > into > "Program Files (x86)". > > Thanks for the suggestion, though. I knew it was there, but hadn't > thought > of it. Very much appreciated. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RC=4093 from TSO ALLOC in compiled REXX
Thanks for the tip but I run both in batch using the same JCL except for the EXEC statement, which either points to IKJEFT01 or to the compiled program. Wrong! SYSPROC is of course changed to STEPLIB also. And the ALLOC is for a temporary data set so the prefix should not come into question anyway, I guess. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Ask the Experts "Shoot-Out"
Jim Mulder wrote: Well, of course it does. The purpose of the DUMP and REIPL options of V XCF,sys,OFF,etc. is simply to set the 0A2 wait state reason code to a value which drives the appropriate AutoIPL actions as defined in the WSAT (Wait State Action Table). See MVS Planning: Operationsfor a description of the WSAT. Jim, Obviously, you should have been one of the experts in the panel. Start pushing your manager *NOW* to let you participate for SHARE in Boston...August 1-5. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RC=4093 from TSO ALLOC in compiled REXX
Try PGM=IKJEFT01,PARM= Bob Staffan Tylen wrote: Thanks for the tip but I run both in batch using the same JCL except for the EXEC statement, which either points to IKJEFT01 or to the compiled program. Wrong! SYSPROC is of course changed to STEPLIB also. And the ALLOC is for a temporary data set so the prefix should not come into question anyway, I guess. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Creating an I/O error
Possibly silly question, but I need to test a SYNAD routine, and I can't think of any way to actually produce an I/O error upon command. Can anyone point out any solutions? Regards, Allen Gainsford Info Developer, Banking Shared Services HP Enterprise Services (South Pacific) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Creating an I/O error
On Sun, 21 Mar 2010 21:23:56 +, Gainsford, Allen wrote: >Possibly silly question, but I need to test a SYNAD routine, and I can't think >of any way to actually produce an I/O error upon command. Can anyone point >out any solutions? > Create a Unix file with lines longer than LRECL; allocate it with FILEDATA=TEXT and read it. With practically any Classic data set, allocate it with overriding BLKSIZE < size of an actual block; read it. Writing is harder. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Creating an I/O error
On Sun, 21 Mar 2010 21:23:56 + "Gainsford, Allen" wrote: :>Possibly silly question, but I need to test a SYNAD routine, and I can't think of any way to actually produce an I/O error upon command. Can anyone point out any solutions? BSAM READ of a smaller incorrect blocksize. Or modify a QSAM DCB with an incorrect BLKSIZE/LRECL. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Creating an I/O error
>> Possibly silly question, but I need to test a SYNAD routine, and I >> can't think of any way to actually produce an I/O >error upon >> command. Can anyone point out any solutions? > >Create a Unix file with lines longer than LRECL; allocate it with >FILEDATA=TEXT and read it. > >With practically any Classic data set, allocate it with overriding >BLKSIZE < size of an actual block; read it. > >Writing is harder. > >-- gil Thanks; worked fine. Cheers, Allen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RC=4093 from TSO ALLOC in compiled REXX
Spot on, Bob. No TSO environment. Thanks. Staffan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Creating an I/O error
> Writing is harder. As I recall, define a DD with DD * and then write to it. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Sunday, March 21, 2010 2:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Creating an I/O error On Sun, 21 Mar 2010 21:23:56 +, Gainsford, Allen wrote: >Possibly silly question, but I need to test a SYNAD routine, and I can't think of any way to actually produce an I/O error upon command. Can anyone point out any solutions? > Create a Unix file with lines longer than LRECL; allocate it with FILEDATA=TEXT and read it. With practically any Classic data set, allocate it with overriding BLKSIZE < size of an actual block; read it. Writing is harder. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Creating an I/O error
Gil wrote me privately and asked if this would cause an ABEND or a SYNAD. I looked up my test job, and yes, it appears that writing output to DD * will cause a SYNAD, not an ABEND, ***provided you give it a blocksize***, i.e. //TESTOUT DD *,BLKSIZE=100 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Charles Mills Sent: Sunday, March 21, 2010 5:34 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Creating an I/O error > Writing is harder. As I recall, define a DD with DD * and then write to it. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re-entrancy problem
The error occurred on the INITAPI
Started 4 tasks 4 ATTACHES
THE RETURN CODE IS
THE ERRNO IS ..000E
THE RETURN CODE IS
THE ERRNO IS ..000E
THE RETURN CODE IS
THE ERRNO IS ..000E
THE RETURN CODE IS
THE ERRNO IS ..000E
The INITAPI is
**
* identify the program to TCP/IP *
**
EZASMI TYPE=INITAPI, Issue INITAPI Macro X
MAXSOC=MAXSOC, SPECIFY MAXIMUM NUMBER OF SOCKETSX
MAXSNO=MAXSNO, (HIGHEST SOCKET NUMBER ASSIGNED) X
ERRNO=ERRNO, (Specify ERRNO field)X
RETCODE=RETCODE, (Specify RETCODE field) X
APITYPE=APITYPE, (SPECIFY APITYPE FIELD) X
ERROR=ERROR, ABEND IF ERROR ON MACRO X
ASYNC=('ECB'), (SPECIFY ECBS) X
TASK=MYTIE, X
I do a STORAGE for 4 MYTIE('s) in my main program and pass each subtask a
TIE as a parm
The MY_PARM is part of my Working Storage Dsect
MY_PARM EZASMI MF=L
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Rob Scott
Sent: Friday, March 19, 2010 7:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Re-entrancy problem
Joe,
Can you tell us more about the failure :
(1) Did it abend? If so - with what code and where
(2) Did it just not POST the ECB?
A few things to check :
(1) Where is "MY_PARM"? - is this in working storage?
(2) How was "MY_PARM" defined?
(3) What was specified on the INITAPI ?
One last "gotcha" with EZASMI is that the "ECB=" keyword must point to a
104-byte field and NOT a 4-byte field.
I know that sounds crazy - but EZASMI uses the last 100 bytes as a
"workarea".
(Why this "workarea" was not a separate keyword I just don't know)
Rob Scott
Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Joe Reichman
Sent: 19 March 2010 10:40
To: IBM-MAIN@bama.ua.edu
Subject: Re-entrancy problem
Hi,
The following code works (ECB is posted by TCP/IP) except when I catalouge
the program RENT=(REUS)
Would anybody have any ideas
*-*
* GET THE SOCKET TO READ *
*-*
MVCCOMM,=CL8'TAKESOCK'
XCMY_PARM(MY_PARM_LEN),MY_PARMCLEAR PARAMTER LIST
LAR10,MY_ECB GET MAIN TASK ECB
STR10,ECB_LISTSTORE IT
LAR10,MVS_ECB GET MAIN TASK ECB
STR10,ECB_LIST+4 STORE IT
OIECB_LIST+4,X'80' MARK END
EZASMI TYPE=TAKESOCKET, Issue INITAPI Macro X
SOCRECV=SOCKET,
X
CLIENT=CLIENT, SPECIFY SUBTASK IDENTIFIER
X
ERRNO=ERRNO, (Specify ERRNO field)
X
RETCODE=RETCODE, (Specify RETCODE field)
X
ECB=MY_ECB,
X
ERROR=ERROR, ABEND IF ERROR ON MACRO
X
TASK=MYTIE,
X
MF=(E,MY_PARM)
*
*WAIT ECB=MY_ECB
*B CK_RET
WAIT 1,ECBLIST=ECB_LIST
L R10,ECB_LIST+4 GET MVS ECB
CLC 1(3,R10),=3X'00' POSTED
BERETURN YES; GO BACK
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
