TAPECOPY problem
Hello, we have the following problem with HSM TAPECOPY. First time it appeared after migration from 1.7 to 1.9. (In 1.7 everything was OK) Each time during TAPECOPY BACK processing (from VTS 3490 virtual tape to 3490 physical tapes), first tape copy finish with the following error: ARC0425I COPY OF ZVA111 FAILED - REASON=29 In documentation I've found following explanation: During processing of the TAPECOPY command, a volume to be copied is of a different length than the volume to which it is to be copied or the input and output tape drives use a different recording technology. DFSMShsm does not allow a TAPECOPY from an enhanced capacity tape cartridge to a standard capacity cartridge, nor does it allow a TAPECOPY from a standard capacity cartridge to an enhanced capacity tape cartridge... However: 1. In 1.7 it worked OK and we didn't change our HSM settings after migration. 2. Error always affect only first tape, next tapes (the same type) are always copied correctly. Our HSM TAPEUTILIZATION settings: ARC0418I TAPEUTILIZATION PERCENT=0068, LIBRARYBACKUP ARC0418I TAPEUTILIZATION PERCENT=0097, UNIT=3490 ARC0418I TAPEUTILIZATION PERCENT=0070, UNIT=VLIB1 (VTS) Part of HSM log: IEC501A M 0A6C,ZVA111,SL,COMP,DFHSM,DFHSM (ZVA111 - 3490 virtual tape) IEC501A M 0801,PRIVAT,SL,COMP,DFHSM,DFHSM(801 - 3490 physical tape drive) IEC705I TAPE ON 0801,105752,SL,COMP,DFHSM,DFHSM,MEDIA2 (105752 - 3490 tape cartridge) ARC0425I COPY OF ZVA111 FAILED - REASON=29 IEC205I SYS00577,DFHSM,DFHSM,FILESEQ=1, COMPLETE VOLUME LIST, VOLS=105752 IEF234E K 0A6C,ZVA111,PVT,DFHSM,DFHSM IEC502E K 0801,105752,SL,DFHSM,DFHSM ... next tapes are copied correctly ARC0422I TAPECOPY COMPLETED - RETURN CODE=4 Where is the source of problem ?? Marcin Wąsik Centrum Komputerowe ZETO S.A. 90-146 Łódź, ul. Narutowicza 136, Polska http://www.ckzeto.com.pl/ http://www.ckzeto.com.pl/ -- 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
Rmm Delete Volume
In the manual it shows the command as: DV volser Release . My Question is can I specify just the prefix of the volume as ' 2* ' in stead of ' 200116' ? -- 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: Rmm Delete Volume
No you will have to specify the entire volser. What you could do
however is produce a clist that will contain all the DV commands below
is the syntax. I am not familiar with using the release as I've only
used force...
//CONFIRM2 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
RMM SEARCHVOLUME VOLUME(2*) OWNER(*) LIMIT(*) -
CLIST(' RMM DV ',' Release')
EXEC 'USERID.EXEC.RMM.CLIST'
John
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Arturo
Sent: Monday, May 04, 2009 6:43 AM
To: IBM-MAIN@bama.ua.edu
Subject: Rmm Delete Volume
In the manual it shows the command as: DV volser Release . My Question
is can I specify just the prefix of the volume as ' 2* ' in stead of '
200116' ?
--
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
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
--
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: TAPECOPY problem
What happens if you try to copy ZVA111 as other than the 1st tape? Why not just create the copies concurrently with the originals? i.e. duplexing This will a) eliminate the need for the tapecopy in the first place b) be sensitive to the length of either virtual or physical media (the shorter one wins, be it virtual or physical snip we have the following problem with HSM TAPECOPY. First time it appeared after migration from 1.7 to 1.9. (In 1.7 everything was OK) Each time during TAPECOPY BACK processing (from VTS 3490 virtual tape to 3490 physical tapes), first tape copy finish with the following error: ARC0425I COPY OF ZVA111 FAILED - REASON=29 In documentation I've found following explanation: During processing of the TAPECOPY command, a volume to be copied is of a different length than the volume to which it is to be copied or the input and output tape drives use a different recording technology. DFSMShsm does not allow a TAPECOPY from an enhanced capacity tape cartridge to a standard capacity cartridge, nor does it allow a TAPECOPY from a standard capacity cartridge to an enhanced capacity tape cartridge... /snip -- 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: DFHSM QUESTION - FRBACKUP
Why paint yourself into a corner? You may want that function in the future, even if you don't need it now. Just do it. There is another APAR OA13453 that required increasing the BCDS recordsize to 2093 to support volume stacking w/encryption anyway. Since the actual record in the BCDS is variable, this change cost's nothing except time. Simply define a new BCDS and specify RECORDSIZE( 344 6544), repro, rename, and restart. You're done! HTH, snip We will be upgrading to z/OS 1.10 in 3 weeks time. We received a notification that if we are using the FRBACKUP function in DFHSM we will need to changed the maximum recordsize of the BCDS to 6544. I looked for the FRBACKUP parm in the DFHSM Parmlib - ARCCMD - but I couldn't find it which would indicate that it is not being used. I also looked for the parm MAXCOPYPOOLTASKS which according to the doc. controls the FRBACKUP. It was niether found. Is there other checks I run so as to rule out the FRBACKUP parm is not being used? /snip -- 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: SDSF problem - sysplex 1.8 1.10 (mea culpa)
It turns out that our MAINVIEW release runs on z/OS 1.10 and __appears__ to work in most cases, but in this one case it does not. I need to upgrade. -- John -- 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: Z/OS Compatibility List
That is IT. I couldn't remember the link. Thank You -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kevin Mckenzie Sent: Friday, May 01, 2009 6:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Z/OS Compatability List I'm not sure if this is exactly what you want, but IBM consolidates information from ISVs. We rely on them to provide the information, so if there's a vendor not on the list, please talk to them and ask the to provide their compatibility information. http://www-947.ibm.com/systems/support/z/zos/planning.html, then choose the release under Vendor software products for z/OS and z/OS.e --- Kevin McKenzie External Phone: 845-435-8282, Tie-line: 8-295-8282 z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 From: Cebell, David cebe...@aafes.com To: IBM-MAIN@bama.ua.edu Date: 05/01/2009 03:59 PM Subject: Z/OS Compatability List Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Does anyone know if there is a CONSOLIDATED listing of mainframe software products And the vendor published compatibility releases needed for the different Z/OS releases. I know we can go to each vendor's website to get this but some crawler should be able to do this. -- 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 -- 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: Assembler and ECBL conversion issues
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Leslie Wagner Sent: Monday, May 04, 2009 10:09 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler and ECBL conversion issues I am the original poster of this on bit.listserv.ibm-main. PJ Farley ccd it here - thanks Pete! You're quite welcome. Glad to help. These assembler modules all do I/O against VSAM and QSAM files. Open, close, gencb, modcb, acb macros mostly that I've seen so far. I'm still going thru them. Some of them were upgraded from older DOS assembler code 37 years ago or so. I think we want to take the path of least resistance here, but also wanted to know just what we might be losing by taking that path. Well, if they're mostly I/O subs you may want to replace them eventually, but for the least resistance path you can just leave them alone for now and try the helper module route I suggested in my first reply. As to what you lose, you can safely assume that the Enterprise COBOL code will occupy more storage than the older COBOL II code, if for no other reason than that Enterprise COBOL uses re-entrant working-storage where VALUE clauses mean that variables are initialized with actual code on first entry rather than just meaning data is compiled into the object code. So keeping the new Enterprise code below the line will result in even less available storage than the current COBOL II code has. As I said earlier, a generic helper module that could call any of these 24-bit modules (LE-enabled assembler or even a COBOL version) would give you breathing room if you can nail down all the possible parameters. Then you can use DATA(31) for all your Enterprise COBOL recompiles and get at least some of the advantages of the conversion right away. BTW, using DATA(24) does not require static links. The simple change to dynamic call instead of static can be combined with DATA(24), so that your new COBOL code resides above the line even if your data is below. OTOH, static links mean lower CALL overhead, so CPU usage may well increase a bit for dynamically-invoked subroutines. If you go the helper module route, that module should be linked AMODE(31)/RMODE(ANY) (and DATA(24) if COBOL) and use dynamic CALL to the assembler subroutines. On the third hand, you really do want to try to avoid the DATA(24)/static link solution if at all possible. IMHO it's the worst of all possible worlds. If you're already managing re-links when a subroutine changes (or if they never do change), I guess I can see a management decision to avoid the work, but only if there is a follow-on plan (with an allocated budget!) to finish the upgrade to get to a full DATA(31) environment in reasonably-sized phases. Feel free to ask more questions as they come up. Regards, Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: Z/OS Compatibility List
Sorry, got make my point on this one. I understand the desire to save time. I have the same desire, but not at the expense of correct information. However, why in the world would you rely on IBM to tell you that a vendors software is up-to-date? The vendors have a hard enough time, and that is getting it first hand, forget about getting is second hand(from IBM). It is your system, not IBM's. I spot checked a few. The link to Compuware take you to document not found, Dino software V5R2 is broken, just to name a couple. How hard is it to make a list of your software, and go to each vendors site? This is something you do once every year or two at most? _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB1G p 616.653.8429 f 616.653.8497 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kevin Mckenzie Sent: Friday, May 01, 2009 6:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Z/OS Compatability List I'm not sure if this is exactly what you want, but IBM consolidates information from ISVs. We rely on them to provide the information, so if there's a vendor not on the list, please talk to them and ask the to provide their compatibility information. http://www-947.ibm.com/systems/support/z/zos/planning.html, then choose the release under Vendor software products for z/OS and z/OS.e --- Kevin McKenzie External Phone: 845-435-8282, Tie-line: 8-295-8282 z/OS BCP SVT, Dept FXKA, Bldg 706/2D38 From: Cebell, David cebe...@aafes.com To: IBM-MAIN@bama.ua.edu Date: 05/01/2009 03:59 PM Subject: Z/OS Compatability List Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Does anyone know if there is a CONSOLIDATED listing of mainframe software products And the vendor published compatibility releases needed for the different Z/OS releases. I know we can go to each vendor's website to get this but some crawler should be able to do this. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is 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
Crazy VSAM question
A programmer has posed this question to me. My response, so far, has been no way. But I'll ask the truly knowledgeable here. We have a KSDS with an AIX. The data in the field which defines the alternate keys is sometimes unknown and coded as LOW-VALUES (0x00's). Well, this has lead to a problem where the number of base records for the unknown value is often quite huge and exceeds the maximum allowable record size on the AIX. This causes the base record add or update to fail. What the programmer wants is a way to tell VSAM that if the AIX key is 0x00s, that it is not necessary to update the AIX at all. I cannot think of any way to do this. Any clever ideas? -- John -- 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: Rmm Delete Volume
Thank you John, That’s what I was looking for. -- 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: Assembler and ECBL conversion issues
I am the original poster of this on bit.listserv.ibm-main. PJ Farley ccd it here - thanks Pete! These assembler modules all do I/O against VSAM and QSAM files. Open, close, gencb, modcb, acb macros mostly that I've seen so far. I'm still going thru them. Some of them were upgraded from older DOS assembler code 37 years ago or so. I think we want to take the path of least resistance here, but also wanted to know just what we might be losing by taking that path. -- 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
DFHSM QUESTION - FRBACKUP
Hallo All Readers, We will be upgrading to z/OS 1.10 in 3 weeks time. We received a notification that if we are using the FRBACKUP function in DFHSM we will need to changed the maximum recordsize of the BCDS to 6544. I looked for the FRBACKUP parm in the DFHSM Parmlib - ARCCMD - but I couldn't find it which would indicate that it is not being used. I also looked for the parm MAXCOPYPOOLTASKS which according to the doc. controls the FRBACKUP. It was niether found. Is there other checks I run so as to rule out the FRBACKUP parm is not being used? Thanks. __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.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: Crazy VSAM question
i do not know of a way to do what you are asking (bypass updating the AIX) - but ... how bout adding a 1-byte field to the file (alt--key-known) when the AIX key is not known - radomize it - and move N to the one-byte field - else use the real AIX-key value and move Y to the new field there are most likely at least 100 things wrong with my suggestion - but it MIGHT work ... Chris Hoelscher Senior IDMS DB2 Database Administrator Humana Inc 502-476-2538 choelsc...@humana.com you only need to test the programs that you want to work correctly The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- 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
CrossPost: Mainframe Poll
Information Weeks May 4 issue is all about virtualization. There is an article (only one) about the mainframe that at least acknowledges that the mainframe exists and can do more but they emphasize at a cost. They are asking those interested in the mainframe to take a poll at: http://www.informationweek.com/poll/mainframes In one question they ask which OS you are using and include IBM Linux - I wasn't aware that there was an IBM Linux which goes to show that they are still ignorant of the mainframe Linux space - but they are asking so let's give them some input. Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: lionel.b.d...@kp.org AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We?re here to make lives better.? ?Never attribute to malice what can be caused by miscommunication.? NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. -- 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: CrossPost: Mainframe Poll
... and Open Solaris as well. Itschak On Mon, May 4, 2009 at 6:44 PM, Lionel B Dyck lionel.b.d...@kp.org wrote: Information Weeks May 4 issue is all about virtualization. There is an article (only one) about the mainframe that at least acknowledges that the mainframe exists and can do more but they emphasize at a cost. They are asking those interested in the mainframe to take a poll at: http://www.informationweek.com/poll/mainframes In one question they ask which OS you are using and include IBM Linux - I wasn't aware that there was an IBM Linux which goes to show that they are still ignorant of the mainframe Linux space - but they are asking so let's give them some input. Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: lionel.b.d...@kp.org AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We?re here to make lives better.? ?Never attribute to malice what can be caused by miscommunication.? NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. -- 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: RECEIVE ORDER ERROR
In defense of selective RECEIVE. Maybe it's because we have several folks 'in charge' of various products; more likely it's because I'm a very disorganized person. I can't keep track of what I should or should not APPLY other than 'all'. Besides IBM's classifications, I get occasional requests from other people to install a PTF or two for the specific product they support. They're all grown-ups. I don't question whether MQ or HSM or IP really does or does not need a particular fix suggested by the respective SME. If I RECEIVE(ALL), how will I keep of what I should APPLY in the next cycle? (Rhetorical question. Suggestions not solicited.) Since I'm not fully capable of any procedure other RECEIVing selectively and then APPLYing all, that will remain my SOP. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com Chase, John jch...@ussco.com To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List ibm-m...@bama.ua Subject .edu Re: RECEIVE ORDER ERROR 04/28/2009 03:36 PM Please respond to IBM Mainframe Discussion List ibm-m...@bama.ua .edu -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Zelden On Tue, 28 Apr 2009 13:11:43 -0700, Edward Jaffe wrote: Chase, John wrote: If I did that, wouldn't I have all of the PTFs that haven't yet gone through CST? Yes, but you can APPLY by SOURCEID(RSU*). Right now, I just RECEIVE ORDER CONTENT(RECOMMENDED), whatever comes back comes back, and I APPLY *all* of it with a canned job stream that's always the same. Simple. The suggestion seems to be to use RECEIVE ORDER CONTENT(ALL) and then selectively manage what comes back. I become the one who decides which fixes have undergone enough testing and which have not. I have to keep track of these numbered/dated RSUs to help understand which fixes I want and which I don't. And, I have to be sure to specify the right RSU value(s) at APPLY time. From where I sit, this process sounds like extra work. Clearly, this is a job to be undertaken by a professional sysprog--something I've never claimed to be. Not any extra work at all. It's just changing where the filter is. Currently you filter at the source by selecting CONTENT(RECOMMENDED). If you change to CONTENT(ALL) and change your APPLY JCL to SOURCEID(RSU*), you are applying the same service. The PRO is that you would have any PTF you needed in an emergency. The CONs are possibly longer download times and storing more PTFs locally. Actually, to apply *everything* you get with CONTENT(RECOMMENDED), you'd need to specify SOURCEIDs RSU*, HIPER and PRP. I've tried it already with one batch of CICS maintenance, using this canned APPLY job: APPLY FORFMID( list of CICS FMIDs ) SOURCEID( RSU* HIPER PRP ) GROUPEXTEND BYPASS( whatever's appropriate for your case) CHECK . Works a treat. -jc- -- 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: CrossPost: Mainframe Poll
On 5/4/2009 at 12:27 PM, Itschak Mugzach imugz...@gmail.com wrote: ... and Open Solaris as well. Well, OpenSolaris does now run on System z (but only on z/VM), so at least they got that right. Not a whole lot else, though. Mark Post -- 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
Assembler and ECBL conversion issues
Absolutely doing static-link below the line should be your LAST choice. Consider: 1) Change static calls to CALL identifier for 24-bit code (Don't change DYNAM/NODYNAM compiler option) and use DATA(24). 2) As others have suggested, see if you need the assembler routines at all. If they are primarily I/O modules, check out the COBOL EXTERNAL attribute and see if you can't (easily) convert them to COBOL. One thing to be VERY careful of when doing batch conversions is to make certain you are aware of performance issues. I have seen VS COBOL II to Enterprise COBOL conversions that died because inadequate time was allocated for performance tuning (especially for LE run-time options and COBOL compiler options). My guess is that your Assembler is NOT LE-enabled which is an entire other area for consideration. If you have any Assembler drivers (rather than subroutines) this becomes a HUGE issue in such a conversion. Leslie Wagner wagn...@finance.nyc.gov wrote in message news:listserv%200905040909091182.0...@bama.ua.edu... I am the original poster of this on bit.listserv.ibm-main. PJ Farley ccd it here - thanks Pete! These assembler modules all do I/O against VSAM and QSAM files. Open, close, gencb, modcb, acb macros mostly that I've seen so far. I'm still going thru them. Some of them were upgraded from older DOS assembler code 37 years ago or so. I think we want to take the path of least resistance here, but also wanted to know just what we might be losing by taking that path. -- 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
EZZ0401I error message
Hi all: We are migrating to z/OS v1.r9 and having troubles getting TCPIP up successfully. We are getting the error message: EZZ0401I SYNTAX ERROR IN FILE: 'SYS2.TCPIP.PARMS(TCPVTZOS)' ON LINE: 439 at 'PUBTCA1' The error occurs for every other line in the file, beginning with: LUMAP PUBTCA1 PUBIP1 LUMAP PUBTCA1 PUBSOM LUMAP PUBTCA1 EASTRAD LUMAP PUBTCA1 PUBIP1 LUMAP POOLTCB1 POOLIP1 LUMAP POOLTCB2 POOLIP2 LUMAP POOLTCB3 POOLIP3 The statements appear to match the syntax description for the LUMAP statement, and worked successfully in z/OS v1.r7. We don't see any reference to specific changes here in the migration manual. Any ideas? Mike Myers Pitt County Memorial Hospital -- The contents of this e-mail (and any attachments) are confidential, may be privileged and may contain copyright material. You may only reproduce or distribute material if you are expressly authorized by us to do so. If you are not the intended recipient, any use, disclosure or copying of this email (and any attachments) is unauthorized. If you have received this e-mail in error, please notify the sender and immediately delete this e-mail and any copies of it from your system. == -- 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: EZZ0401I error message
On Mon, 4 May 2009 15:29:18 -0400, Mike Myers mike.my...@pcmh.com wrote: Hi all: We are migrating to z/OS v1.r9 and having troubles getting TCPIP up successfully. We are getting the error message: EZZ0401I SYNTAX ERROR IN FILE: 'SYS2.TCPIP.PARMS(TCPVTZOS)' ON LINE: 439 at 'PUBTCA1' The error occurs for every other line in the file, beginning with: LUMAP PUBTCA1 PUBIP1 LUMAP PUBTCA1 PUBSOM LUMAP PUBTCA1 EASTRAD LUMAP PUBTCA1 PUBIP1 LUMAP POOLTCB1 POOLIP1 LUMAP POOLTCB2 POOLIP2 LUMAP POOLTCB3 POOLIP3 The statements appear to match the syntax description for the LUMAP statement, and worked successfully in z/OS v1.r7. We don't see any reference to specific changes here in the migration manual. Any ideas? Mike Myers Pitt County Memorial Hospital Is this the same exact data set as 1.7 or a copy? Do you number it when copying if so? What if you put semicolons after each statement? LUMAP PUBTCA1 PUBIP1 ; LUMAP PUBTCA1 PUBSOM ; ... Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: EZZ0401I error message
At the 1.9 level the TN3270 server is a requirement, not optional. If you have not done so yet, you should take every statement dealing with TN3270 beginning with Telnetparms and ending with Endvtam and place them in a separate profile member. Then study the instructions for creating the TN3270 started task. This can be done at your current level. Otherwise, just pull all those statements from the TCPIP startup configuration profile. On Mon, 4 May 2009 14:36:52 -0500, Mark Zelden mark.zel...@zurichna.com wrote: On Mon, 4 May 2009 15:29:18 -0400, Mike Myers mike.my...@pcmh.com wrote: Hi all: We are migrating to z/OS v1.r9 and having troubles getting TCPIP up successfully. We are getting the error message: EZZ0401I SYNTAX ERROR IN FILE: 'SYS2.TCPIP.PARMS(TCPVTZOS)' ON LINE: 439 at 'PUBTCA1' The error occurs for every other line in the file, beginning with: LUMAP PUBTCA1 PUBIP1 LUMAP PUBTCA1 PUBSOM LUMAP PUBTCA1 EASTRAD LUMAP PUBTCA1 PUBIP1 LUMAP POOLTCB1 POOLIP1 LUMAP POOLTCB2 POOLIP2 LUMAP POOLTCB3 POOLIP3 The statements appear to match the syntax description for the LUMAP statement, and worked successfully in z/OS v1.r7. We don't see any reference to specific changes here in the migration manual. Any ideas? Mike Myers Pitt County Memorial Hospital Is this the same exact data set as 1.7 or a copy? Do you number it when copying if so? What if you put semicolons after each statement? LUMAP PUBTCA1 PUBIP1 ; LUMAP PUBTCA1 PUBSOM ; ... Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: Anyone Know of a Good Pocket Calculator Like HP with Hex capabilities
There are free apps for iPhones; one is called Missing Calc and it has Hex, Decimal, Octal, and Binary Radix as well as ASCII, UTF 8 and UTF 16 Encodings. Barry Merrill -- 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
TSO XMIT blocksize
Is there any way to get TSO XMIT to use a reasonable blksize? I reblocked an XMIT dataset of a PDS to BLKSIZE=27920 and TSO RECEIVE had no trouble processing it. I assume that means there is no technical reason that the blocksize has to be 3120 (at least for my simple purposes). Is there an option that allows XMIT to use the blocksize of a pre- allocated output dataset? BTW, I'm on z/OS 1.8. Pat O'Keefe -- 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: EZZ0401I error message
On Mon, 4 May 2009 14:42:17 -0500, Matthew Stitt mathwst...@bellsouth.net wrote: At the 1.9 level the TN3270 server is a requirement, not optional. If you have not done so yet, you should take every statement dealing with TN3270 beginning with Telnetparms and ending with Endvtam and place them in a separate profile member. Then study the instructions for creating the TN3270 started task. This can be done at your current level. Otherwise, just pull all those statements from the TCPIP startup configuration profile. Good catch. You are probably right. I didn't even consider that since the OP wrote: We don't see any reference to specific changes here in the migration manual. We did this at z/OS 1.6... which was a long time ago already. There were lots of warning to do it before 1.9 - including the migration checker. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: TSO XMIT blocksize
++ USERMOD (LM00062) REWORK(2008001) /* TRANSMIT OUTDA() FORCES THE BLKSIZE OF THE OUTPUT DATA SET TO 3120 (X'0C30'). THIS MOD SETS IT TO 0 - SYSTEM DET. BLKSIZE */ . ++ VER (Z038) FMID(HTE7750) . ++ ZAP (INMXM) . NAME INMXM VER 1A24 ,0C30 REP 1A24 , -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick O'Keefe Sent: Monday, May 04, 2009 15:07 To: IBM-MAIN@bama.ua.edu Subject: TSO XMIT blocksize Is there any way to get TSO XMIT to use a reasonable blksize? I reblocked an XMIT dataset of a PDS to BLKSIZE=27920 and TSO RECEIVE had no trouble processing it. I assume that means there is no technical reason that the blocksize has to be 3120 (at least for my simple purposes). Is there an option that allows XMIT to use the blocksize of a pre- allocated output dataset? BTW, I'm on z/OS 1.8. Pat O'Keefe -- 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: EZZ0401I error message
Matthew: Thanks. We are following that path and it looks like that will be the solution. Mike Matthew Stitt mathwst...@bellsouth.net 5/4/2009 3:42 PM At the 1.9 level the TN3270 server is a requirement, not optional. If you have not done so yet, you should take every statement dealing with TN3270 beginning with Telnetparms and ending with Endvtam and place them in a separate profile member. Then study the instructions for creating the TN3270 started task. This can be done at your current level. Otherwise, just pull all those statements from the TCPIP startup configuration profile. On Mon, 4 May 2009 14:36:52 -0500, Mark Zelden mark.zel...@zurichna.com wrote: On Mon, 4 May 2009 15:29:18 -0400, Mike Myers mike.my...@pcmh.com wrote: Hi all: We are migrating to z/OS v1.r9 and having troubles getting TCPIP up successfully. We are getting the error message: EZZ0401I SYNTAX ERROR IN FILE: 'SYS2.TCPIP.PARMS(TCPVTZOS)' ON LINE: 439 at 'PUBTCA1' The error occurs for every other line in the file, beginning with: LUMAP PUBTCA1 PUBIP1 LUMAP PUBTCA1 PUBSOM LUMAP PUBTCA1 EASTRAD LUMAP PUBTCA1 PUBIP1 LUMAP POOLTCB1 POOLIP1 LUMAP POOLTCB2 POOLIP2 LUMAP POOLTCB3 POOLIP3 The statements appear to match the syntax description for the LUMAP statement, and worked successfully in z/OS v1.r7. We don't see any reference to specific changes here in the migration manual. Any ideas? Mike Myers Pitt County Memorial Hospital Is this the same exact data set as 1.7 or a copy? Do you number it when copying if so? What if you put semicolons after each statement? LUMAP PUBTCA1 PUBIP1 ; LUMAP PUBTCA1 PUBSOM ; ... Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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 -- The contents of this e-mail (and any attachments) are confidential, may be privileged and may contain copyright material. You may only reproduce or distribute material if you are expressly authorized by us to do so. If you are not the intended recipient, any use, disclosure or copying of this email (and any attachments) is unauthorized. If you have received this e-mail in error, please notify the sender and immediately delete this e-mail and any copies of it from your system. == -- 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: Crazy VSAM question
I'm not a DBA, but I would think there would be a problem with an AIX with a large number of unknows in it. If there are a large number of rows with an index of hex zeros, is the AIX really helping any? Tom Kelman Enterprise Capacity Planner Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Hoelscher Sent: Monday, May 04, 2009 10:53 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Crazy VSAM question i do not know of a way to do what you are asking (bypass updating the AIX) - but ... how bout adding a 1-byte field to the file (alt--key-known) when the AIX key is not known - radomize it - and move N to the one-byte field - else use the real AIX-key value and move Y to the new field there are most likely at least 100 things wrong with my suggestion - but it MIGHT work ... Chris Hoelscher Senior IDMS DB2 Database Administrator Humana Inc 502-476-2538 choelsc...@humana.com you only need to test the programs that you want to work correctly The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- 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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: TSO XMIT blocksize
On Mon, 4 May 2009 15:17:55 -0500, Field, Alan C. alan.c.fi...@supervalu.com wrote: ++ USERMOD (LM00062) REWORK(2008001) ... ++ ZAP (INMXM) . ... Uh, thanks, but that probably isn't going to fly. We've got all non-HIPR maint frozen until we disappear from the face of the earth later this year. :-( But I guess that answers my question. Pat O'Keefe -- 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: Anyone Know of a Good Pocket Calculator Like HP with Hex capabilities
On 1 May 2009 12:09:52 -0700, in bit.listserv.ibm-main you wrote: Also it should do Scientific notation, as well as simple Divide and Multiply I prefer a small one so I can carry it on trips. I use an application called MathU Pro on my HTC 8525 (a Windows Mobile smartphone). It has the same general functions as an HP16C (although it does not claim to be an HP16C emulator). Does decimal, hex, binary, octal as well as scientific functions. And it uses RPN!!! It's available for both Palm OS and Windows Mobile, costs around $45. Eric -- Eric Chevalier E-mail: et...@tulsagrammer.com Web: www.tulsagrammer.com Is that call really worth your child's life? HANG UP AND DRIVE! -- 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: TSO XMIT blocksize
On Mon, 4 May 2009 15:07:01 -0500, Patrick O'Keefe wrote: Is there an option that allows XMIT to use the blocksize of a pre- allocated output dataset? BTW, I'm on z/OS 1.8. No! I tried the stress test: I used the OUTDDNAME(X) option, where X was allocated to a new member of a PDS with a pre-existing member and BLKSIZE=27920. TRANSMIT changed the block size to 3120, and an attempt to copy the earlier member with IEBGENER now fails with: IEB351I I/O ERROR ,XMITATTR,STEP,41C8,D,SYSUT1 ,READ ,WRNG.LEN.RECORD,0025000B06,BSAM WAD? N, BAD! It should be APARable behavior when any utility changes the attributes of an existing data set in such a way as to make it unreadable. It's always been that way? I don't care! It's documented that way? I still don't care! It's just wrong! BSAM? I thought IEBGENER used QSAM. -- 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
Windows based, programmer's hex calculator
I started to use DreamCalc, scientific version some time ago. The cost is modest, US$ 15.99. http://www.dreamcalc.com It supports hex calculations in both normal and RPN mode. It supports 32 and 64 bit operations. Using 64 bit floating mode gives sign-less arithmetic. Lots of functions and conversions, nice to use, well integrated with Windows. Krzysztof Bytnerowicz Software Engineer Ca Inc. -- 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: TSO XMIT blocksize
Gil, Nope, it's BSAM. Had a cranial page fault last week trying to increase the chained blocks per SSCH without increasing NCP. DOH! Ron BSAM? I thought IEBGENER used QSAM. -- 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
