Re: TSO receive on MultiVolume PS error
IND$FILE is only useful for small datasets. Its performance is woeful for larger datasets and it is not well supported under some 3270 emulators, I would use FTP/SFTP/NFTP etc instead. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Anthony L. Zak Sent: Monday, 23 May 2016 1:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO receive on MultiVolume PS error TRANSMIT, a TSO command processor running on the z/OS M/F, repackages the input dataset and then writes it to JES to be handled via NJE which means the data can be RECEIVEd wherever there is NJE connectivity. IND$FILE piggybacks over a 3270 type session with Comm Server and AFAIK only gets you as far as the host you have the 3270 session with. One could use them in series. How about using z/OS Explorer which is a 21st century product? Sent from my Verizon Wireless BlackBerry -Original Message- From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sender: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> Date: Sun, 22 May 2016 20:53:26 To: <IBM-MAIN@LISTSERV.UA.EDU> Reply-To: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: [IBM-MAIN] TSO receive on MultiVolume PS error On 2016-05-22, at 14:31, R.S. wrote: > W dniu 2016-05-20 o 18:33, Paul Gilmartin pisze: >>> >> My quick check for this is (IIRC): >> >> cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum >> >> ... at both ends of the transfer and compare the checksums and lengths. >> > I remember how I spent half a day on such problem. > I had to download PTF package then move it from one PC to another, using pendrive, then upload it to z/OS and do SMPE tasks. > I took a lot of time to recognize the reason is failing pendrive (nota bene with IBM logo! ;-))) ). It simply changed some bytes within the file with no CRC32 error or so. It was the last thing on the list of suspects. > Ouch! Do you mean the pendrive reported no error, or that you got the same CRC32 on the originating PC and the destination PC? Windows is woefully deficient in checksum utilities. One must install one. I use Cygwin. But my suggestion was elliptical. I should have mentioned the need to use TRANSMIT with the OUTDSN option; FTP/SFTP/IND$FILE; then compare checksums; then RECEIVE with the INDSN option. Can TRANSMIT use IND$FILE for the TCP/IP challenged? Can IND$FILE transfer z/OS to z/OS? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO receive on MultiVolume PS error
I only use XMIT a.b DA(dsn) OUTDA(FB80) for smallish datasets that I may wish to read on a PC, otherwise a DFDSS Dump and TRS has been my standard for years and can handle single or multiple datasets. I used this where my intent is to move data from one system to another via any other type of system (Linux/Wndows/OS X) or just to move the data. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mick Graley Sent: Tuesday, 24 May 2016 1:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TSO receive on MultiVolume PS error Yes XMIT definitely supports DSORG=PS RECFM=U data sets. Good example being DFDSS dumps. I regularly use DFDSS to dump multiple data sets, then XMIT that dump data set to get a very portable RECFM=FB LRECL=80 version of the dump. Cheers, Mick. On 20 May 2016 at 18:36, Jesse 1 Robinson <jesse1.robin...@sce.com> wrote: > OP referred to a 'PS with Fo[r]mat U'. Does XMIT/RECEIVE even support PS > files with RECFM U? The only RECFM U files I know of are load modules, but > they are PO, not PS. In any case the error message refers to the XMITted > file, not the target. > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-302-7535 Office > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Friday, May 20, 2016 9:33 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: TSO receive on MultiVolume PS error > > On Fri, 20 May 2016 06:14:44 -0500, Elardus Engelbrecht wrote: >> >>Are you sure your dataset has been transferred properly and fully and without >>errors before you tried out RECEIVE? >> > My quick check for this is (IIRC): > > cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum > > ... at both ends of the transfer and compare the checksums and lengths. > > (Or you could write an assembler program using CSNBOWH.) > > -- gil > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Space Calculation on z/OS sytems
If you have SAS and MXG then you have all the tools you need, for a cost. If not, then you may have to roll your own out of DCOLLECT (Disk & HSM data) and TMC (Tape) data, have seen it done with Rexx. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Tuesday, 24 May 2016 6:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Space Calculation on z/OS sytems Mainframe Mainframe wrote: >We have requirement of calculating the space utilized / consumed by our >all z/OS systems as well as by Tape libraries . Few points >1) I can find with the list of volumes used/allocated by z/OS systems and this >will give me the space given to these system. But how can i find the exact >space consumed by these host from these volume. Look at ISMF, get a list of volsers, look at pull down menu item 'List'. Select 'Print'. Choose your columns including 'ALLOC SPACE' and you have your report. Or you can use DCOLLECT. There are other free and expensive solutions. Search IBM-MAIN archives for that. >2) We are using HSM for backup to tape and I am not finding ways to calculate >the space consumed by these tapes. What tape management system do you have? 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: Product name by module
TAD4z is a great Australian developed product. It stores its data in DB2 tables and its Knowledge Base for product/vendor/version etc. is updated monthly. It covers all load from all environments although CICS is normally excluded, and it does not matter where the load module comes from, it will find it. OMVS is not involved except to extract executable info from USS HFS/ZFS files. The product was originally developed to identify unused products that companies pay continually for, so you can use it to assist in controlling your software budget. For pricing ask your IBM rep. I personally have no interest in TAD4z except I know the developers and the product very well and I am currently employed by IBM till the end of this Month, yes another RA. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lucas Rosalen Sent: Saturday, 21 May 2016 7:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Product name by module I know of IBM Tivoli Asset Discovery for z/OS (TADz). It does a very good job and can show you many different graphical reports in a web application called Analyzer (of course you also need to have this part installed/configured) getting data straight from OMVS. I don't know the price of it, as we wouldn't get that far supporting out clients, but I know we were able to identify some softwares like the one you mentioned. Even if their modules were called in STEPLIBs/JOBLIBs. Probably some other ISVs software can do the same (and possibly even better?), but I don't have any personal experience with them. Regards, Lucas On May 21, 2016 10:15, "Peter" <dbajava...@gmail.com> wrote: Thanks all for a reply and that was very useful. The LPAR has lot of Obsolete entry on LINKLST and APF. So is there any product which can tell me which LINKLISTED or APFed dataset are really used ? Peter On May 19, 2016 5:46 PM, "Peter Relson" <rel...@us.ibm.com> wrote: > I would have added, just in case the excellent advice previously given > didn't pan out: > > You might well get a clue simply from the name of the load module, as > "module prefixes" are pretty carefully managed by most. > The prefix might not tell you all you want to know but will at least > usually get you to the owning company who could then provide more > granular info. > > I'm not sure how accessible to the general public is the list of > module prefixes vs owning company, but the information is available as > a last resort. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: [SURVEY] What ISPF terminal model do you use
I use the -oversize option as -oversize 134x60.
Cheers,
Paul Gillis
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Dyck, Lionel B. (TRA)
Sent: Friday, 11 March 2016 3:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: [SURVEY] What ISPF terminal model do you use
Isn't there a -model option something like:
-model n
Where n is 2 for mod 2, 3 for mod 3, etc.
I don't have access to x3270 right now but that is what I seem to recall.
--
Lionel B. Dyck (Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI
Service Delivery & Engineering
Office: 512-326-6173
Cell: 925-348-0237
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Martin Packer
Sent: Thursday, March 10, 2016 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: [SURVEY] What ISPF terminal model do you use
Maybe I'm being thick here but with X3270 I think I'm stuck at 32 x 80 - and
not because of the emulator but because I don't know how to get the z/OS
TSO/ISPF environment I'm using to take advantage of more.
Cheers, Martin
Martin Packer,
zChampion, Principal Systems Investigator, Worldwide Cloud & Systems
Performance, IBM
+44-7802-245-584
email: martin_pac...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From: "R.S." <r.skoru...@bremultibank.com.pl>
To: IBM-MAIN@LISTSERV.UA.EDU
Date: 10/03/2016 16:23
Subject:Re: [SURVEY] What ISPF terminal model do you use
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
24x80
Yes, I have colour monitor, flat one, actually two of them, 27" each.
And still the most popular (3270) screen resolution I use is 24x80.
Atavism ;-)
I also use 43x80 and rarely 24x132 or 42x132.
BTW: I wish I would have any resolution *I want* and my application simply
supported it. That wasn't case at least for ControlM panels ("illegal"
resolutions caused abend).
--
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
authorized 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.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
www.mBank.pl, e-mail: kont...@mbank.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.2016 r. kapitał zakładowy
mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
--
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: COBOL v5
Remember one of those from the early 70s when one of our monthly ISAM update jobs would run for almost 24 hours. One of the smarter guys around at the time looked at it and sorted the update file, which was mainly inserts, backwards and the job ran in less than 30 minutes, he understood ISAM inserts really well. He was one of my colleagues that pointed me toward systems programming. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Savor, Thomas (Alpharetta) Sent: Friday, 29 January 2016 10:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 I'm not sure about the ISAM part. I HATED ISAM. If you enjoy watching your jobs grind away seemingly foreverthen you liked ISAM. I've always loved VSAMmaybe because I hated ISAM so much. Ever have ISAM job that did an Update in Place (not file in/ file out)ugghh ! Thanks, Tom -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Thursday, January 28, 2016 5:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: COBOL v5 W dniu 2016-01-28 o 19:44, Charles Mills pisze: > I cannot speak for IBM, but IMHO they may have felt that way at one > time, but EC 5.2 is clearly an investment on IBM's part and a > commitment to the future of COBOL. > > You can't make an omelet without breaking eggs. "Add new features" and > "make it go into an old-fashioned load module" are potentially > inconsistent requirements. > Well, IMHO there are two kinds of mainframe customers: a) Legacy We don't want PDSE, We don't want binder. We don't want SMS. We still want VSAM passwords. We don't want VSAM. ISAM was good. We don't want FICON. We want ESCON ...for BUS connectivity. We want 3274... b) modern We want COBOLE AMODE64. We want HFS/ZFS >4GB. We want DSORG=PO to be multi-volume. We want JCL modifications. Etc. The problem is satisfying b) means troubles for a) group. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized 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. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.955.696 zotych. -- 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: Need to find the DSN from where load module was loaded
No, nothing in the Unix space Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, 29 January 2016 4:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need to find the DSN from where load module was loaded On Thu, 28 Jan 2016 19:36:19 +1100, Paul Gillis wrote: >We have a standard home grown utility, a little like Eileen's, scanning LPA, >Dynamic LPA, Nucleus etc. It also scans all ISPF libraries if allocated, >including SYSPROC and SYSEXEC. Not sure why it was written originally but I >have used it to find what libraries load modules exist in that were mentioned >in the Health Checker when the size of Private Storage above and below changes >significantly. Also comes in handy when users complain that x does not >function properly and if they run this routine and find x in their own >libraries then they have to resolve it themselves, otherwise we have to. Our >customer also uses the code to perform their own basic diagnosis before >calling for help. > >Goes hand in hand with a duplicate member finder that I wrote years ago for >times when we had to do something similar. > ISPF DDLIST is a sore point to me. DDLIST MEMBER command fails to find members of UNIX directories in a mixed concatenation of UNIX directories and Classic PDS[E]s, even though the UNIX member may occur in a catenand earlier than the one reported. Does your tool or Eileen's do better? IBM calls the DDLIST behavior WAD. I believe STEPLIB must not be a mixed concatenation (I haven't tried). Mixed concatenation of SYSEXEC works but is not supported. Mixed concatenation of HLASM SYSLIB is fully supported; IBM has repaired problems I've reported. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need to find the DSN from where load module was loaded
We have a standard home grown utility, a little like Eileen's, scanning LPA, Dynamic LPA, Nucleus etc. It also scans all ISPF libraries if allocated, including SYSPROC and SYSEXEC. Not sure why it was written originally but I have used it to find what libraries load modules exist in that were mentioned in the Health Checker when the size of Private Storage above and below changes significantly. Also comes in handy when users complain that x does not function properly and if they run this routine and find x in their own libraries then they have to resolve it themselves, otherwise we have to. Our customer also uses the code to perform their own basic diagnosis before calling for help. Goes hand in hand with a duplicate member finder that I wrote years ago for times when we had to do something similar. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Walt Farrell Sent: Thursday, 28 January 2016 6:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Need to find the DSN from where load module was loaded On Wed, 27 Jan 2016 10:21:55 -0600, Support, DUNNIT SYSTEMS LTD. <supp...@dunnitsys.com> wrote: >Thank you for sending me the code. I haven't looked at it yet but I'll narrow >down what I'm talking about: > >1. Environment is batch or ISPF. Check is during execution. Code is Assembler. >2. Looking for origin DSN of program module which was loaded via LOAD macro. >3. Loadlib can be in JOBLIB, STEPLIB or ISPF LIBDEF. >4. There may be multiple loadlibs concatenated together in the DD allocation. You still haven't said why you are doing this, and what you hope to accomplish with the information. That may be important to getting the best answer. For the general case, as far as I know, you cannot determine the answer with certainty. For some specific cases of module access you may be able to determine the answer with a fair degree of certainty, but probably not 100% unless you are the owner of the code that loaded the module, and can guarantee the environment that code is running in. -- Walt -- 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: So Long, and Thanks For All The Fish
Always enjoyed reading your posts, enjoy life away from us. Regards, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shane Ginnane Sent: Friday, 1 January 2016 1:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: So Long, and Thanks For All The Fish Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DLIB volume for SAD
If that is where you IPL SAD from, then there is no major issue as the space required is small. You may have to rebuild your SAS IPL text after maintenance or OS upgrade but if you do that after every IPL then there is no issue where the SAD IPL text lives. If that is where your SYS1.SADMP dataset resides, then it may be too small, unless it is spread over multiple volumes. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nathan Astle Sent: Monday, 2 November 2015 6:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DLIB volume for SAD Hi Apology for asking a dummy question. Why do we use Distribution library volume dataset while taking a SAD for a z/OS ? Nathan -- 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: Fortran, assembly programmers ... NASA needs you - for Voyager . Job For Shane?
Loved the last sentence, personally I don't know about the current penetration of Fortran, but how many ancient z/OS shops do not run COBOL. Apart from those who have PL/1 of course. "Along with NASA's aging fleet of spacecraft, many businesses still rely on ancient languages such as Fortran or COBOL for specialized tasks and critical infrastructure." Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Monday, 2 November 2015 5:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Fortran, assembly programmers ... NASA needs you - for Voyager . Job For Shane? http://www.theregister.co.uk/2015/10/31/brush_up_on_your_fortran/ -- 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: Silent IBM-MAIN?
Nah, I reckon it's 1/n + Six = 7, so your answer is only correct if n = 1. Not so silent Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Tuesday, 11 August 2015 4:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Silent IBM-MAIN? H, IBM-MAIN is s silent? Or is it dead, moribund, passed out, under 6 feet soil, finished, knocked-out? Whats the matter? All and everyone that really busy yesterday or on a well deserved holiday? Or trying to figure out a failsafe/crashproof upgrade to z/OS v2.1? Oh, well, here is a mathematical puzzle for you to cheer you up: (Are you mathematically challenged? ;-D ) Prove that ( 1 + Sin X ) / n = 7 Simple: just cancel out letter n, you get: ( 1 + Si x ) = 7 thus, ( 1 + 6 ) = 7 !!! Voila! One test fewer to you. ;-) 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: Library out of space issue while APPLY RSU
Please do not tell me that you are applying maintenance to a running system. Because if you are then you have probably just destroyed your IPL volume. Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Wednesday, 22 July 2015 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Library out of space issue while APPLY RSU Hello Group, I am applying RSU on z/OS 1.13 system and encountered D37-04 and E37-04 for various datasets like D37-04 SYS1.SASMMOD1 --- is used by XCFAS , LLA, D37-04 SYS1.SISPLOAD --- is used by XCFAS , LLA, D37-04 SYS1.SGIMLMD0 --- is used by XCFAS , LLA, D37-04 SYS1.NUCLEUS --- D37-04 SYS1.LINKLIB --- is used by XCFAS , LLA, E37-04 SYS1.CNMLINK --- is used by XCFAS , LLA, NETVIEW Now, renaming the dataset to .old and then create new dataset big big size and then using ISPF option 3.3 for copy, we have only option left is 1) Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 2) For CNMLINK dataset, I will have to stop NETVIEW as well along with Unallocate linkist (SETPROG LNKLST,UNALLOCATE) and then stop LLA ( P LLA) 3) But for NUCLEUS dataset, I will have to bring down alll system in sysplex and then do remaining and creating bigger dataet and then copy content using ISP 3.3 Do we have any other way to overcome this issue rather then copping LLA and XCFAS etc. Regards Venkat -- 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: RSU APPLY ISSUE
RESTORE the usermod APPLY the PTF Correct the usermod with PRE(UK81531) and any other logical changes REEIVE the updated usermod Apply the usermod Cheers, Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of venkat kulkarni Sent: Tuesday, 21 July 2015 8:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RSU APPLY ISSUE Hello, We are installing RSU on z/OS 1.13 system and in apply check process we encountered below issue. GIM38201E ** THERE IS A MODID ERROR FOR SRC ENTRY ASMADOPT IN SYSMOD UK81531. GIM31901ISYSMOD UK81531 DOES NOT SPECIFY SP1BAB0 ON THE PRE OR SUP OPERAND. SP1BAB0 IS THE RMID FOR SRC ASMADOPT THAT IS CURRENTLY INSTALLED. GIM22601IAPPLY PROCESSING FAILED FOR SYSMOD UK81531. SP1BAB0 is the user MOD we applied before. Can you please suggest. -- 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: EOJ, literally.
Congratulations Tony, I see a few of us have accumulated more than 40 years in the trade, but 2 months shy of 50 years is an impressive achievement. I have less than 5 years to catch up, but don't think I will. Enjoy your retirement in good health. Regards, Paul Gillis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tail of MVS SYSLOG
The ops words were I want to send this data to an external system for analysis. So I saw no need for head/tail capability on z/OS. Might be roundabout but works fine for me may work fine for the op. Just another way to get the data out of JES2 to where it can be used. Paul Gillis From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Saturday, 15 November 2014 1:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Tail of MVS SYSLOG On Fri, 14 Nov 2014 23:05:25 +1100, Paul Gillis pgil...@pc-link.com.au wrote: I have used the @BRLOG rexx exec, freely supplied by IBM, to perform post IPL analysis on the head of the active syslog. Redbook http://www.redbooks.ibm.com/redbooks/pdfs/sg247419.pdf points to ftp://www.redbooks.ibm.com/redbooks/SG247419 to download SG277419.zip and @brlog.rex is in the ch06 directory. The Redbook chapter 6 says you can direct the output to a dataset or to a path name where you can head/tail the SYSLOG data. Where I see: If the path name parameter is present, @BRLOG copies all SYSLOG data sets to a temporary MVS data set and copies using OCOPY to the path that is specified. ... Kinda roundabout, isn't it? Why not write directly to the path specified? Not indicative of a high degree of craftsmanship. ...Finally, using the TSO command, OEDIT allows the user to view it. Copying the path name does use a Carriage Return/Linefeed (CR/LF) to separate the file records. CRLF!? Ugh! Not the z/OS Unix System Services convention. I see no mention of tail in Chapter 6, much less of tail -f (presuming that such dynamic updating was among the OP's objectives). I doubt that tail -f would be effective. -Original Message- From: Paul Gilmartin Sent: Friday, 14 November 2014 1:56 AM On Thu, 13 Nov 2014 08:39:13 -0600, Elardus Engelbrecht wrote: To Lizette: The word 'tail' is an Unix term where you send the last x lines to somewhere else. I believe there is also something like 'head' for send the first x lines to somewhere else. Generally useful with the pipe command. The OP may be thinking of tail -f fllename, where the -f option means to periodically (every few seconds) to extract (stat()) the size of the file and send any characters not previously sent (in the fashion of SDSF DOWN MAX nn). The OP may have wanted such dynamic updating. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tail of MVS SYSLOG
I have used the @BRLOG rexx exec, freely supplied by IBM, to perform post IPL analysis on the head of the active syslog. Redbook http://www.redbooks.ibm.com/redbooks/pdfs/sg247419.pdf points to ftp://www.redbooks.ibm.com/redbooks/SG247419 to download SG277419.zip and @brlog.rex is in the ch06 directory. The Redbook chapter 6 says you can direct the output to a dataset or to a path name where you can head/tail the SYSLOG data. Paul Gillis -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, 14 November 2014 1:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Tail of MVS SYSLOG On Thu, 13 Nov 2014 08:39:13 -0600, Elardus Engelbrecht wrote: Kacynski, Walt wrote: Does anyone know of a way to tail the JES based MVS SYSLOG to an external system and/or unix based syslog? I want to send this data to an external system for analysis. ... PRINT ODSN dataset ... ... Then use ocopy to put it to an unix folder. I use the SDSF API (Rexx) to IEBGENER directly from spool to a UNIX file. No temp data set needed. But only from job output; untested for SYSLOG. Does SDSF provide PRINT OUTDD ddname? To Lizette: The word 'tail' is an Unix term where you send the last x lines to somewhere else. I believe there is also something like 'head' for send the first x lines to somewhere else. Generally useful with the pipe command. The OP may be thinking of tail -f fllename, where the -f option means to periodically (every few seconds) to extract (stat()) the size of the file and send any characters not previously sent (in the fashion of SDSF DOWN MAX nn). The OP may have wanted such dynamic updating. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx (was: OT? ... deliberately unfriendly)
I have been using Regina Rexx for some years, started when I was to teach a Rexx course and wanted a good Windows Rexx capability. The OS interfaces are different, but easy enough to use, and it is well documented. It can be found at http://regina-rexx.sourceforge.net/ it is obviously being updated regularly as I am using 3.5 and 3.7 is available and the price is right. Sample of I/O code below. Other OS interfaces I have not used, no need yet. /* Read the file into an array */ INFILE1 = C:\WineBase32\TextFile\WineList.csv lines = 0 do while lines(infile1)0 lines = lines + 1 iline.lines = linein(infile1) end iline.0 = lines Paul -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Ford Sent: Friday, 29 November 2013 6:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rexx (was: OT? ... deliberately unfriendly) Gil, Haven't used Regina , but have used Open Object Rexx and like the Linux interface. Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Nov 28, 2013, at 11:20 AM, Paul Gilmartin paulgboul...@aim.com wrote: On Thu, 28 Nov 2013 07:41:14 -0600, Mike Schwab wrote: http://www.rexxinfo.org/ http://www.rexxla.org/links/ On Thu, Nov 28, 2013 at 3:29 AM, Elardus Engelbrecht wrote: deleted I miss Rexx in command line for OS/2. I believe there are Rexx for windoze, but I haven't looked at it. deleted Google finds many hits for REGINA CYGWIN. But any Rexx stands or falls on the quality of its host command interfaces. THE? Would you want a comand interface to Notepad? I am very pleased with the SYSCALL command environment of Rexx for z/OS (called TSO, but I can forgive that). -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Book Enquiry
Indeed. And given the dearth of opportunities I see advertised and sites disappearing, hard to argue. The O/S continues being developed, as does the hardware, but the puddle we all play in continues to evaporate. Shane ... Retirement is just around the corner, as that puddle shrinks. Anyone younger than 50 ready to take over for the next few years? Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: useful? XML encoded SMF.
BMC do the SMF to XML in their performance product, that I played with a few years ago. Personally I prefer Barry's solution, as it just does it as is without XML, but I am biased having used it for more years than I care to remember. Paul G... -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shane Ginnane Sent: Wednesday, 25 July 2012 9:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: useful? XML encoded SMF. On Tue, 24 Jul 2012 18:00:47 +0200, R.S. r.skoru...@bremultibank.com.pl wrote: ... ??? Lol - well, what followed didn't transcribe too well. Interesting product - some time ago I looked at knocking up some C code to ship RMF data from the Distributor down to a Linux client so I could do a poor mans RMFIII. Ugly, seriously ugly to get big-endian binary data full of binary zeroes down a little-endian client. Had a play with Python for the GUI, but it was hard work. Then IBM announced the were planning on shipping the CIM server (I *did* say some time ago). Whoot !!!. Time passed, the world changed ... But there is a lot to be said for a properly constructed XML solution to this data -all of it, not just (some of) the RMF records. As an aside, I was also going to plug Barrys solution (lots of customers like that), but he got in first. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
