Re: LOGR for Dummies?
Why do you fear Logr records will be lost? If you specify AUTODELETE(NO) and RETPD(0), Logr will delete records as CICS indicates, not by its own decisions. If you want to backup your logstream data, I wonder what you can do with the backups. Kees. McKown, John [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I've been told that another sysprog was given a method by the ex-CICS sysprog on how to ensure that no LOGR records were lost. Apparently he has gone a round tuit yet. Below is the JCL which unloads the LOGR for one of the regions. I will wait to see what the appropriate method to ensure no loss of records is. He may suggest your method. However, I wonder about it efficacy due to the fact that this job is running while the CICS is up . I.e. the two steps may get different records because more records could be added after the first, non-delete, copy is run. No, we cannot take the region down. Not even at 02:30 hours. This is a political decision, not a technical one. Hopefully nobody is doing anything at 02:30, but I wouldn't guarantee it. //CPYDFH5A EXEC PGM=FILESAVE //STEPLIB DD DISP=SHR,DSN=SYS3.FILESAVE.PROD.LOADLIB // DD DISP=SHR,DSN=SYS3.FILESAVE.V4R0.LOADLIB // DD DISP=SHR,DSN=SYS3.ICEAM1.SICELINK ALLOW DYNALLOC=OFF //DFSPARM DD * ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
What is driver 55k in z machines ?
I'm applying a PSP for a new machine (z890-460). In documentation I found many times references to 'Driver 55K'. As I'm not a z/OS sysprog, can anyone explain me what it is ? A piece of HW ? Thank in advance Max Scarpa DB2 sysprog -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is driver 55k in z machines ?
This is the level of the microcode for the machine. Ask your IBM tech if you already have it installed, and if not ask him to install it. Gadu -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Max Scarpa Sent: Wednesday, June 22, 2005 12:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: What is driver 55k in z machines ? I'm applying a PSP for a new machine (z890-460). In documentation I found many times references to 'Driver 55K'. As I'm not a z/OS sysprog, can anyone explain me what it is ? A piece of HW ? Thank in advance Max Scarpa DB2 sysprog -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is driver 55k in z machines ?
http://www-1.ibm.com/servers/eserver/zseries/pso/cftable.html You should really get off your fingers and use Google. I'm applying a PSP for a new machine (z890-460). In documentation I found many times references to 'Driver 55K'. As I'm not a z/OS sysprog, can anyone explain me what it is ? A piece of HW ? Thank in advance Max Scarpa DB2 sysprog -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html John Cassidy Dipl-Ing Schleswigstr. 7 51065 Cologne Tel: +41 76 4198 658 EU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is driver 55k in z machines ?
Been awake since 05:40 actually, never heard of someone in our business without web access. Must be a heavy outfit you are with. End sssn Thank you for your replies. snip You should really get off your fingers and use Google. end snip If I had an access to web for sure I'd have done it. I'm not able to googlesearch via e-mail. Sorry if I woke you up. Max Scarpa -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html John Cassidy Dipl-Ing Schleswigstr. 7 51065 Cologne Tel: +41 76 4198 658 EU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Upgrading from z/900 to z/990 and Cisco CIP HCD Definitions
Is it possible that the CIP routers that are configured as SCTCs/RS6K are not running CSNA? IP will will work with either one and we are trying to figure out if we need to change our HCD for a DR on Z990s. We have been having problems at DR testing with CSNA and CIP microcode is at 28-18. Thanks Phyllis Boruk -Original Message- From: Bruce Hewson [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 12:23 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Upgrading from z/900 to z/990 and Cisco CIP HCD Definitions Hello Mark, I dont see why they say that. I still have Cisco CIP routers connected to my boxes... I haven't changed their definitions, even though we have upgraded from 9672's to z900's to z990s. I have both 3172 and SCTC coded for different connections. They work...so I cant justify changing them. On Tue, 21 Jun 2005 03:54:32 -0700, Mark T. Regan, K8MTR netsfw- [EMAIL PROTECTED] wrote: We will be upgrading from a z/900 to a z/990 next month and we still have some Cisco CIP cards to support for one of our customers. I asked Cisco if their CIP cards support the z/990, and they said yes, but they added: However from the M/F point of view you may have to define the HCD CIP definitions as 3172. Apparently with some of the new processors you can't define the CIP links as CTC or RS6K only as 3172. Currently we have them defined as SCTC and they are connected via ESCON Director switches. Does anyone if we will have to change UNIT= setting or not? Thanks. Regards Bruce Hewson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Another OS/390 to z/OS 1.4 migration question (COBOL)
Hi folks Our developers are getting IGYPS0157-E and IGYPS0158E messages when they try and compile a CICS COBOL program on z/OS 1.4 in Enterprise Cobol of z/OS and OS/390 V3.2. I can't find these blasted messages documented anywhere!! Is there some convoluted format for decoding them? I suspect it's just a COBOL options member problem, but I need to see the message description. It only seems to happen when the CICS precompiler (CICS 4.1.0) is included first. The texts of the messages are: IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. IGYPS0158-E A nonnumeric or national literal containing double-byte characters was found which exceeded the maximum literal length or reached end of area B before terminating. A literal delimiter was placed at column 72 of line This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
look here: http://www-1.ibm.com/support/docview.wss?uid=swg21163906 -Original Message- From: Perryman, Brian [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 7:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Another OS/390 to z/OS 1.4 migration question (COBOL) Hi folks Our developers are getting IGYPS0157-E and IGYPS0158E messages when they try and compile a CICS COBOL program on z/OS 1.4 in Enterprise Cobol of z/OS and OS/390 V3.2. I can't find these blasted messages documented anywhere!! Is there some convoluted format for decoding them? I suspect it's just a COBOL options member problem, but I need to see the message description. It only seems to happen when the CICS precompiler (CICS 4.1.0) is included first. The texts of the messages are: IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. IGYPS0158-E A nonnumeric or national literal containing double-byte characters was found which exceeded the maximum literal length or reached end of area B before terminating. A literal delimiter was placed at column 72 of line This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System intends this e-mail message, and any attachments, to be used only by the person(s) or entity to which it is addressed. This message may contain confidential and/or legally privileged information. If the reader is not the intended recipient of this message or an employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are prohibited from printing, copying, storing, disseminating or distributing this communication. If you received this communication in error, please delete it from your computer and notify the sender by reply e-mail. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
Brian, It has to do with the CICS Translator option you Are using, not COBOL option. I think the correct option is now COBOL3, but my mind is a little rusty on the topic. Dave Dave Jousma Principle Systems Programmer Fifth Third Bank Information Technology (Phone) 616-653-8429 (Fax) 616-653-8497 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Perryman, Brian Sent: Wednesday, June 22, 2005 7:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Another OS/390 to z/OS 1.4 migration question (COBOL) Hi folks Our developers are getting IGYPS0157-E and IGYPS0158E messages when they try and compile a CICS COBOL program on z/OS 1.4 in Enterprise Cobol of z/OS and OS/390 V3.2. 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
Thanks Dave, I'll probably try that too! - This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RES: How to know the z/OS version by TSO login.
In ISPF (PDF), enter option 7.3 (Dialog Test and Variables) and look for ZOS390RL variable. It contains your level of operating system. Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto Banco Bradesco S/A 4254/DPCD/Alphaville Suporte Técnico - Software Básico Mainframes Tel:55 11 4197-2021 Fax:55 11 4197-2814 [EMAIL PROTECTED] -Mensagem original- De: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] nome de Bo Xie Enviada em: segunda-feira, 20 de junho de 2005 23:24 Para: IBM-MAIN@BAMA.UA.EDU Assunto: How to know the z/OS version by TSO login. Hi, Someone told me to type in D IPLINFO in master console to know the z/OS version. But I can not touch the master console and get the following errors by TSO login: - READY D IPLINFO IKJ56500I COMMAND D NOT FOUND READY /D IPLINFO IKJ56621I INVALID COMMAND NAME SYNTAX READY - How to know the z/OS version by TSO login? Thank you! Best Regards, Xie Bo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html AVISO LEGAL BR Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. +**+ LEGAL ADVICE BR This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is driver 55k in z machines ?
... I'm applying a PSP for a new machine (z890-460). In documentation I found many times references to 'Driver 55K'. As I'm not a z/OS sysprog, can anyone explain me what it is ? A piece of HW ? ... It's the level of the code in the HMC. They have to be at specified levels to support new(er) z/BOXen. -teD (The secret to success is sincerity. If you can fake that, you've got it made!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICSF
Hi, Make sure that the SRVCLASS of ICSF is set to SYSSTC or something high. We had a problem that caused an outage because the performance and tuning group set the task's SRVCLASS below our onlines' SRVCLASS. This was fine until CPU reached 100% and ICSF stopped getting dispatched. This prevented several tasks from using ICSF's services which hosed up production. Gabe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Name/Token Services in COBOL?
On 6/21/2005 5:29 PM, Farley, Peter x23353 wrote: Not to mention the other language copy members there (IEANTC, IEANTPAS, IEANTPLI). BTW, the C language sample in SYS1.SAMPLIB(IEANTC) has an error in the #pragma's for the 64-bit IEANT functions: They are each declared as linkage(...,OS64_NOSTACK), but OS64_NOSTACK is not a supported option of #pragma linkage in the IBM C compiler. To whom does a simple application programmer like myself complain about this erroneous sample? How do I get a corrected sample into SYS1.SAMPLIB the next time my sysprogs refresh/update the system? Not that I'm doing any 64-bit work in C yet, I just want the compiler warning eliminated. Members of SYS1.SAMPLIB are (in my experience) generally APARable, so you would probably ask your system programmer to contact the IBM Support Center and open a defect PMR. Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Washington Post: 40 Million Credit Card #s Hacked
In [EMAIL PROTECTED], on 06/21/2005 at 08:23 PM, Tony Babonas [EMAIL PROTECTED] said: Not true, The fact that you lucked out doesn't mean that it's safe to inhale the stuff. An EDS employee had to be treated after going back[1] into the computer room to turn off the system. [1] On his own initiative. It's easier to get forgiveness than to get permission. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HALON et al
In [EMAIL PROTECTED], on 06/22/2005 at 11:41 AM, Shane Ginnane [EMAIL PROTECTED] said: I can only own up to being in 2. In neither case was I affected by the gas - I was out the door as soon as I heard it drop. *VERY* good incentive to get moving. Shane IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 22/06/2005 11:23:25 AM: Not true, I've been in 3 HALON dumps back in the days it was THE method for computer room FS. One must exit quickly as it will make you short of breath at high enough concentrations since it displaces oxygen. Don't assume that it's safe just because the two of you lucked out. An EDS employee had to get medical care after going back[1] into the machine room to turn off the equipment. [1] At his own initiative; I doubt that he would have been allowed to had he announced his intentions up front. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Name/Token Services in COBOL?
Thanks, Walt. I'll try that route. Peter -Original Message- From: Walt Farrell [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 8:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Name/Token Services in COBOL? Snipped Members of SYS1.SAMPLIB are (in my experience) generally APARable, so you would probably ask your system programmer to contact the IBM Support Center and open a defect PMR. Walt _ 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downgrade 9672
Yes, you can pay IBM $5,000 to $10,000 dollars to make it an R16, R26, etc. -Original Message- Hi Listers, We have an IBM 9672-R56 hardware. Is there any way we can downsize it to a lower capacity so that we can use it for testing. We understand that IBM has dropped marketing support for this hardware. Regards, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Disclaimer: This e-mail message is intended only for the personal use of the recipient(s) named above. If you are not an intended recipient, you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. This e-mail expresses views only of the sender, which are not to be attributed to Rite Aid Corporation and may not be copied or distributed without this statement. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hardware DASD design question.
In a message dated 6/22/2005 7:23:43 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Only certain drives. The S/360 DASD and the original S/370 DASD did not have skip displacement, although they did have alternate tracks. IIRC, the 3330 was the first DASD that had skip displacements. Before leaving the factory, a new disk was subjected to rigorous testing in a very sensitive environment. If a bad spot was found on a track that was small enough to be covered by skip defects, one or more defective spots were indicated on the track by recording their offset from the track's index point in special 2-byte fields called skip displacements. The controller had logic to look for this info on the track and, if found, it would automatically skip over the defective spots thus marked. If a defective spot was too large to be covered by all possible skip defects on one track, then an alternate track might be assigned or, if the platter had too many such tracks, the entire platter would be rejected. All skip defects found and assigned in the factory were recorded in the diagnostic tracks area, accessible only to authorized programs. The max number of defects per track grew larger over the years as recording densities got higher. I think the 3330 had one, 3340s and 3350s had three, and 3375s, 3380s, and 3390s allowed up to seven skip defects per track. But all that is arcane virtual history now, as no new SLED 3390s have been manufactured by any vendor for many years. Only RAIDed FBAs are produced now. Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downgrade 9672
I am not sure if it would be worth it, but you could contact a third party vendor and see if you could trade down. Instead of paying money. you might be able to get paid for the downgrade. However, since you could probably buy an R16 or R26 for $ 5,000, the net difference may not pay for the shipping and CE services for the install. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HALON et al
In a message dated 6/22/2005 7:24:23 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Not true, I've been in 3 HALON dumps back in the days it was THE method for computer room FS. One must exit quickly as it will make you short of breath at high enough concentrations since it displaces oxygen. I was in a controlled carbon dioxide dump in a computer room once. You have 10 to 15 seconds to exit the room before you can no longer see, as the CO2 darkens and you could no longer find your way to the door. Also, the CO2 will suffocate you in a few minutes if you don't get out. It was an interesting and tense few seconds. Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
If you didn't upgrade your COBOL as well as z/OS, then I would be REALLY surprised in this change occurring. The COBOL documentation talks about the change from NODBCS to DBCS as the default compiler option - in newer releases of Enterprise COBOL. There should ALSO be a change from FLAG(I) to FLAG(I,I) so that these messages SHOULD have appeared in the source code exactly by the line that had the problem. FYI, What the change from NODBCS to DBCS means is that *if* you have hex OD and OE in your alphanumeric literals, they are treated as DBCS control characters. NOTE WELL: COBOL compiler messages (IGY) are *not* documented; they are self-documenting. If your application programmers can't figure out these specific messages, I would suggest additional training for them. If they don't know WHY they are getting the messages now (but not before), then I suggest you provide them references to the COBOL Migration Guide which does talk about such changes (NODBCS to DBCS). Finally, it does sound as if you may want to switch your site default to NODBCS - unless you also have DBCS applications. The difference between COBOL2 and COBOL3 compiler options MAY influence some of this, but isn't the real problem with these messages. Perryman, Brian [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] i.com... Hi folks Our developers are getting IGYPS0157-E and IGYPS0158E messages when they try and compile a CICS COBOL program on z/OS 1.4 in Enterprise Cobol of z/OS and OS/390 V3.2. I can't find these blasted messages documented anywhere!! Is there some convoluted format for decoding them? I suspect it's just a COBOL options member problem, but I need to see the message description. It only seems to happen when the CICS precompiler (CICS 4.1.0) is included first. The texts of the messages are: IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. IGYPS0158-E A nonnumeric or national literal containing double-byte characters was found which exceeded the maximum literal length or reached end of area B before terminating. A literal delimiter was placed at column 72 of line -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Supported interface to set/retrieve TCBUSER field NON-authorized?
Rolf, Sorry for the delayed reply, but I did not see your message until I browsed the newsgroup today. I normally only read from the mailing list. That's an interesting hack, thanks for the info. It never hurts to have another tool in your back pocket for when it is needed. Peter -- Forwarded message -- From: Rolf Ernst Date: Mon, 20 Jun 2005 22:45:51 -0500 Subject: Re: Supported interface to set/retrieve TCBUSER field NON-authorized? To: Let me suggest the old hat trick for anchoring a bit of information by TCB then: Pick up the TCBFSA point off the TCB off PSATOLD. This is key 8 storage unless there are highly unusual circumstances. Pick any reasonable register from 2-12 in this save area. It is a bit of a hack since you do not know whether anunpody else executing under this TCB will use this save area location but if you have a pretty good idea under which environment you are executing - it will do. Something like L R1,PSATOLD L R1,TCBFSA-TCB(,R1) ST R2,28(,R1) would save the contents of R2 in the first save area. This will do no harm when returning control to the attacher. Albeit, it's a hack. /re _ 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downgrade 9672
At that price it would make more sense to do it yourself! How on earth do IBM arrive at that figure? Or you could buy a used R16 etc. for less money - try ebay! Mike On Wed, 22 Jun 2005 08:44:47 -0400, Larry Kraus [EMAIL PROTECTED] wrote: Yes, you can pay IBM $5,000 to $10,000 dollars to make it an R16, R26, etc. -Original Message- Hi Listers, We have an IBM 9672-R56 hardware. Is there any way we can downsize it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/OS stand-alone dump
What the name of manual that contain information for stand-alone dump for z/OS 1.4? Jason Lowe - Mainframe Systems - Cornell Information Technologies [EMAIL PROTECTED] (607) 255-7851 The Supreme Court has surrendered. It has destroyed the Civil Rights Bill, and converted the Republican party into a party of money rather than a party of morals. Frederick Douglass, 1894 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downgrade 9672
I remnember Texas Tech getting a speed upgrade to there 370/145 back in the 70's. It consisted of the CE removing three loops from the 145's microcode. The price tag for this upgrade? A cool $ 50K! Michael Ross wrote: At that price it would make more sense to do it yourself! How on earth do IBM arrive at that figure? Or you could buy a used R16 etc. for less money - try ebay! Mike On Wed, 22 Jun 2005 08:44:47 -0400, Larry Kraus [EMAIL PROTECTED] wrote: Yes, you can pay IBM $5,000 to $10,000 dollars to make it an R16, R26, etc. -Original Message- Hi Listers, We have an IBM 9672-R56 hardware. Is there any way we can downsize it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS stand-alone dump
Jason, If you mean the basics - z/OS V1R4.0 MVS Diagnosis: Tools and Service Aids Otherwise, you could use the online bookmgr z/OS 1.4 bookshelf and search for what you are looking for: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/IEA2BK34 Lizette Koehler --- Snip What the name of manual that contain information for stand-alone dumpfor z/OS 1.4? Jason Lowe - Mainframe Systems - Cornell Information Technologies --- Unsnip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMPE - copying products to new Global Zone
On Wed, 22 Jun 2005 10:04:24 -0400, Martin, Mike [EMAIL PROTECTED] wrote: Hi all, Let's say I have a Global zone with products A and B. During the install of a new version for product B, I decide to create a new Global CSI (for product B). How can I update this new Global CSI with the information about product A, so I can delete the old Global CSI? Mike Martin FONT SIZE=1 FACE=ARIAL^ This email may contain confidential and privileged material for the sole use of the intended recipient. If you are not the intended recipient, please contact the sender and delete all copies. Any review or distribution by others is strictly prohibited. Personal emails are restricted by policy of the State Employees' Credit Union (SECU). Therefore SECU specifically disclaims any responsibility or liability for any personal information or opinions of the author expressed in this email. /FONT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html To merge global zones, use the GZONEMERGE command, described in the SMP/E Commands manual. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Supported interface to set/retrieve TCBUSER field NON-authori zed?
For vendors there has been a viable alternative to CVTUSER or RYO techniques for a while now. IBM can assign a slot in the vendor nee customer CVT table anchored from the ECVT. ECVTCTBL DCV(CSRCTABL) Customer anchor table. * Slots assigned by IBM. * Ownership: Callable Services. See http://bama.ua.edu/cgi-bin/wa?A2=ind9812L=ibm-mainP=R92723I=1 Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From IBM's perspective the installation is the user. TCBUSER is available to the installation[1]; it was never intended for end users. Similarly for CVTUSER. [1] Not 3rd party software vendors, treading on each other's heels. -- Shmuel (Seymour J.) Metz, SysProg and JOAT This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
What's the 2nd level system for z/VM or z/OS?
Hi, The following sentences include 2nd level,but I don't know what it is. --- login to system: IF running on 2nd level: Login as xxx NOTE: When first IPL-ed, you need to change the password. So for password, enter: aaa and then change it to: bbb IF running on SERVER1: login as yyy --- I guess 2nd level system means IPL a z/OS image from z/VM and login as IBMUSER. Am I right? Or is there any detailed reference about it? (I googled but find nothing about it.:( ) Thank you very much! Best Regards, Xie Bo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downgrade 9672
... However, since you could probably buy an R16 or R26 for $ 5,000, the net difference may not pay for the shipping and CE services for the install ... The net software difference may. But, I recall one ISV (from Islandia NY) Who would not refund any money. Just gave out credits, which were useless unless you bought more product. (Not an increase in existing) -teD (The secret to success is sincerity. If you can fake that, you've got it made!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
Bill Klein wrote: If you didn't upgrade your COBOL as well as z/OS, then I would be REALLY surprised in this change occurring. The COBOL documentation talks about the change from NODBCS to DBCS as the default compiler option - in newer releases of Enterprise COBOL. There should ALSO be a change from FLAG(I) to FLAG(I,I) so that these messages SHOULD have appeared in the source code exactly by the line that had the problem. FYI, What the change from NODBCS to DBCS means is that *if* you have hex OD and OE in your alphanumeric literals, they are treated as DBCS control characters. And I can't figure out why they made that change, since DBCS is, supposedly, on its eventual way out, to be replaced by NATIONAL (Unicode). Any idea why the default was changed? Especially since the vast majority of US shops do not even use DBCS data? NOTE WELL: COBOL compiler messages (IGY) are *not* documented; they are self-documenting. If your application programmers can't figure out these specific messages, I would suggest additional training for them. Thanks, Bill, I think. But I agree with another poster who suggested perhaps some messages are not as self-documenting as the compiler writers think they are. Maybe some training on English? I guess the kind of training we (and, presumably other training vendors) offer on COBOL would provide the background for programmers to be more likely to understand the messages. If they don't know WHY they are getting the messages now (but not before), then I suggest you provide them references to the COBOL Migration Guide which does talk about such changes (NODBCS to DBCS). Finally, it does sound as if you may want to switch your site default to NODBCS - unless you also have DBCS applications. The difference between COBOL2 and COBOL3 compiler options MAY influence some of this, but isn't the real problem with these messages. Again, why the IBM-supplied compiler default was changed to DBCS is a mystery. Or at least a curiosity. Kind regards, -Steve Comstock The Trainer's Friend, Inc. http://www.trainersfriend.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downgrade 9672
On Wed, 22 Jun 2005 09:35:14 -0500, SArnett [EMAIL PROTECTED] wrote: I remnember Texas Tech getting a speed upgrade to there 370/145 back in the 70's. It consisted of the CE removing three loops from the 145's microcode. The price tag for this upgrade? A cool $ 50K! Pretty extortionate... I'm sure there are third-party companies that did/do this kind of thing a hell of a lot cheaper than IBM... Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
Cobol decided that its internal messages were SO wonderful that they no longer needed a messages manual. Yes, really. I found this by opening a PMR with IBM. You can run the following program (Cobol 3.3) : //RUNIVP EXEC IGYWCLG,PARM.COBOL=RENT,REGION=0M, // PARM.LKED='LIST,XREF,LET,MAP' //GO.SYSOUT DD SYSOUT=* //*COBOL.SYSIN DD DISP=SHR,DSN=IGY.V3R3M0.SIGYSAMP(IGYIVP) //COBOL.SYSIN DD * IDENTIFICATION DIVISION. PROGRAM-ID. ERRMSG. /* And it will create a listing of all of the messages that cobol can do. However, I looked in my listing for the IGYPS messages and I couldn't find them. So I recommend you open a PMR with IBM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
Yeah, but unfortunately all this does is give a dump of the messages. No further information beyond what you get when the message happens for real. Some of those messages don't make a whole lot of sense - even if they're supposed to be written so well they don't need further explanation. -Original Message- From: John Mattson [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 10:41 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another OS/390 to z/OS 1.4 migration question (COBOL) Cobol decided that its internal messages were SO wonderful that they no longer needed a messages manual. Yes, really. I found this by opening a PMR with IBM. You can run the following program (Cobol 3.3) : //RUNIVP EXEC IGYWCLG,PARM.COBOL=RENT,REGION=0M, // PARM.LKED='LIST,XREF,LET,MAP' //GO.SYSOUT DD SYSOUT=* //*COBOL.SYSIN DD DISP=SHR,DSN=IGY.V3R3M0.SIGYSAMP(IGYIVP) //COBOL.SYSIN DD * IDENTIFICATION DIVISION. PROGRAM-ID. ERRMSG. /* And it will create a listing of all of the messages that cobol can do. However, I looked in my listing for the IGYPS messages and I couldn't find them. So I recommend you open a PMR with IBM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html E-MAIL CONFIDENTIALITY USE NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. In addition, you are strictly prohibited from using, disseminating, distributing, copying, or storing this message and any attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
In many cases it's not a description of the message that's needed, it's what caused it and what your subsequent options for fixing it are that's needed. I can see that most of the messages from a compiler would indeed be self-documenting and quite rightly so, particularly since the reader is probably the programmer and therefore the one that caused the error situation to occur. Messages alerting of errors caused by external events are a different ball game however and should flipping well be documented! This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HALON et al
Both Halon (which was bad for the Ozone layer) and a more environmentally friendly replacement 1,1,1,2,3,3,3-heptafluoro-propane (manufactured under names such as HFC-227ea, FM-200, FE-227) have a minimum concentration at which they will suppress fires, and a higher concentration at which they become toxic. If I remember correctly, the size of the effective, nontoxic range is not that large, and smaller for Halon than HFC-227ea. IF the fire suppression system is properly designed and sized for the area covered, concentrations would not be toxic; but, I have also read such things as possible effects of long-term exposure to lower level concentrations of HFC-227 are not well understood, so erring on the side of caution where possible sounds advisable. More importantly, if these chemicals are discharged because a fire is in progress, chemical byproducts of the combustion itself and the byproducts of the reaction of the fire suppressant with the fire ARE most likely toxic and exposure should be avoided. I don't remember how Halon functions, but my understanding of HFC-227ea is that in contact with fire it undergoes a chemical reaction that both absorbs heat and also consumes some oxygen at the point of the fire, and the combination of these extinguishes the fire. I think the effective fire suppression concentration of HFC-227 is somewhere in the 5% - 10% range (maybe less), so at worst only 10% of the air is displaced and the reduction in oxygen concentration in the room caused by the chemical discharge would be relatively minor, say from 20% down to 18%. Shane Ginnane wrote: I can only own up to being in 2. In neither case was I affected by the gas - I was out the door as soon as I heard it drop. *VERY* good incentive to get moving. Shane IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 22/06/2005 11:23:25 AM: Not true, I've been in 3 HALON dumps back in the days it was THE method for computer room FS. One must exit quickly as it will make you short of breath at high enough concentrations since it displaces oxygen. I can best describe the experience as running at 10,000 feet elevation. -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMPE - copying products to new Global Zone
SMP BUILDMCS?? Martin, Mike [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 06/22/2005 09:04 Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject SMPE - copying products to new Global Zone Hi all, Let's say I have a Global zone with products A and B. During the install of a new version for product B, I decide to create a new Global CSI (for product B). How can I update this new Global CSI with the information about product A, so I can delete the old Global CSI? Mike Martin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DASD and Mirroring
Ron - Thank you for your follow up. I thought that Skip was making a point about the importance of the role of the application. If not, then I must respectfully *disagree* with Skip. I am concerned that many still cling to the misperception that a 'fuzzy' copy is acceptable as is. As you very correctly point out, a 'fuzzy' copy is ok if, and only if, the application suite expects and deals with such. Hal. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ron and Jenny Hawkins Sent: Tuesday, June 21, 2005 5:53 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DASD and Mirroring Hal, I'm not so certain that you are agreeing to the same point that Skip is making. I take Skip's point as meaning that the success of any Remote Copy design requires attention to the creation of IO consistency in the event of a failure. On the other hand your point to me applies to the ability of an application to recover from an abrupt failure, independent of whether Remote Copy is used or not. The ability to restart an application or a batch stream is not a delivered by Remote Copy. If a site fails the Online and Batch must recover in the same manner irrespective of whether the systems restart in the original centre, or fails over to the DR Centre. The open files may be recovered, deleted, rolled-back/forward, etc - whatever is required to get started. Disk Mirroring delivers a customer the same restart ability in both sites, providing IO Consistency is also delivered by the Remote Copy architecture. It doesn't matter whether restart is in the original copy or the mirrored copy, open datasets should already be dealt with by the application. Ron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Name/Token Services in COBOL?
They are each declared as linkage(...,OS64_NOSTACK), but OS64_NOSTACK is not a supported option of #pragma linkage in the IBM C compiler. I am told that the z/OS 1.5 compiler and up should support this option (though perhaps it is not properly documented). If true, that obviously doesn't do you any good if you're on z/OS 1.4 or earlier. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Washington Post: 40 Million Credit Card #s Hacked
Edward E. Jaffe wrote: R.S. wrote: Timothy Sipples wrote: I think it's Windows Key-K (or something like that). But a lot of keyboards don't have Windows keys (good!), and it's obscure anyway. ...and there are lot of localised versions of Windows. K doesn't work in polish version, while Ctrl-Alt-Del and then ENTER is international. It's not Windows+K ... it's Windows+L. And Ctrl+Alt+Del is no longer international. On my Windows XP SP2 desktops at both home and office, this keystroke does nothing more than bring up the Windows XP Task Manager. Windows-L doesn't work in polish version also. Ctrl-Alt-Del invokes menu with defaulted option LOCK. So sequence of keyestrokes: Ctrl-Alt-Del and then ENTER locks any Windows (NT) computer, regardless of localisation. I didn't mean reboot machine, absolutely. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICSF
Mark Zelden wrote: On Tue, 21 Jun 2005 13:49:22 -0500, Ward, Mike S [EMAIL PROTECTED] wrote: The usage domains do match the LPARs. That was a recommendation that I found in the Installation Redbook. One other thing. If I set up the keys in 1 LPAR can the other LPAR use them or do I have to go through the process for each LPAR? Since the LPARs are on the same CEC (box), then you don't have to do anything. If they were on separate CECs, then you would go through the same process to load the master keys, but you don't re-init the CKDS (INIT CKDS == N). Do you mean ICSF initialization ? IMHO it doesn't matter same CEC or no. You have to initialize ICSF on every LPAR independently. In fact initialization process consist of entering master keys and optionally initialization CKDS/PKDS. If you want to share the keys, then you should share CKDS/PKDS and enter the same master keys on every LPAR (CEC doesn't matter) using it. HTH Regards -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Name/Token Services in COBOL?
Thanks, Peter, and yes, we are at z/OS 1.4. So why should 1.4 SAMPLIB have 1.5-only content? Is that still APAR-able? Peter -Original Message- From: Peter Relson [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 12:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Name/Token Services in COBOL? They are each declared as linkage(...,OS64_NOSTACK), but OS64_NOSTACK is not a supported option of #pragma linkage in the IBM C compiler. I am told that the z/OS 1.5 compiler and up should support this option (though perhaps it is not properly documented). If true, that obviously doesn't do you any good if you're on z/OS 1.4 or earlier. Peter Relson z/OS Core Technology Design _ 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COBOL compiler messages (was: Another OS/390 to z/OS 1.4 migration question (COBOL)
I started a project that I never finished (much less updated for the latest compiler). If you check out my web page at: http://home.comcast.net/~wmklein/IBM/ErrMsg.htm It has an annotated version of the ERRMSG output - with a link to the place in the COBOL documentation that relates to the specific error message. ALL of these messages are self-documenting in MY opinion, but I do understand non-COBOL programmer SysProgs having problems with them. If you find my page useful (but incomplete) please send me private email - and I'll put it back on my more active to-do list. wmklein at ix.netcom.com Perryman, Brian [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] i.com... In many cases it's not a description of the message that's needed, it's what caused it and what your subsequent options for fixing it are that's needed. I can see that most of the messages from a compiler would indeed be self-documenting and quite rightly so, particularly since the reader is probably the programmer and therefore the one that caused the error situation to occur. Messages alerting of errors caused by external events are a different ball game however and should flipping well be documented! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CICS, COBOL, COBOL2, COBOL3, and DBCS (was: Another OS/390 to z/OS 1.4 migration question (COBOL)
The COBOL2 CICS Translator option was removed from CICS TS and then re-introduced by APAR PQ84313. It is my understanding that if you use COBOL3, then you can use either the DBCS or NODBCS compiler option - but that with older COBOL and COBOL2 translator options, you will have problems with using the DBCS compiler option. Recommendation(s): Make certain that you use a supported translator - and if you need/want COBOL2 support that you have APAR PQ84313 installed. Use COBOL3 for translating any currently supported COBOL compiler source code. McKown, John [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Perryman, Brian Sent: Wednesday, June 22, 2005 6:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Another OS/390 to z/OS 1.4 migration question (COBOL) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
Steve Comstock [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... snip And I can't figure out why they made that change, since DBCS is, supposedly, on its eventual way out, to be replaced by NATIONAL (Unicode). Any idea why the default was changed? Especially since the vast majority of US shops do not even use DBCS data? NSYMBOL(National) *requires* (forces on) DBCS, so actually having/allowing the DBCS option is a pre-requisite for having Unicode support. There are some long and painful internal discussions (between myself and the IBM ANSI COBOL rep) and within the J4 group about exactly what is Standard conforming behavior when you have control characters within an alphanumeric literal. I won't go into them here, but I semi-understand the IBM position that ALLOWING national character strings within an alphanumeric literal is a good thing when you MAY use X0E type notation *if* you want to have those x'0d' and x'0e' within literals. The change in defaults WAS highlighted in announcements, migration guides, and installation material - but what its IMPLICATIONS were - are probably unclear to most programmers (application or systems). As stated in another note, if you use the COBOL3 CICS translator option, you will never have a problem with this (for CICS generated code) and the amount of user code with hex 0E and 0D intentionally within NON-DBCS alphanumeric literals is so small that I suspect this should not be a major problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Removal of FMID
On Thu, 27 Jan 2005 18:17:17 -0500, Shmuel (Seymour J.) Metz [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 01/27/2005 at 08:05 AM, Paul Gilmartin [EMAIL PROTECTED] said: RESTORE very much presumes you haven't done an ACCEPT. ACCEPT is pretty customary for FUNCTIONs. Correct. Standard way to delete an accepted function is: 1. RECEIVE, APPLY, ACCEPT a dummy sysmod to delete function. 2. UCLEDIT to delete dummy sysmod. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Greetings, Today we were (re)discussing the fact that SMPE has no direct command to deinstall functions. I thought that many moons ago I submitted a SHARE requirement to provide this functionality, but looked today and did not see it on the SHARE website or in the manuals for SMPE. Does anyone know of the status of providing this functionality to SMPE? I can submit another SHARE requirement, if necessary. Cheers... Michael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
- Original Message - From: Bill Klein [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, June 22, 2005 9:53 AM snip IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. IGYPS0158-E A nonnumeric or national literal containing double-byte characters was found which exceeded the maximum literal length or reached end of area B before terminating. A literal delimiter was placed at column 72 of line snip NOTE WELL: COBOL compiler messages (IGY) are *not* documented; they are self-documenting. If your application programmers can't figure out these specific messages, I would suggest additional training for them. If they don't know WHY they are getting the messages now (but not before), then I suggest you provide them references to the COBOL Migration Guide which does talk about such changes (NODBCS to DBCS). FYI, This self-documenting stuff is NOT IBM STANDARD!! IBM's official stance on messages is that ALL messages should be documented, with the appropriate Programmer and Operator response fields documented. I had this same argument with COBOL level 2 when I called in this problem. My exact words were HTF am I supposed to know that this error message was caused by you changing the default from NODBCS to DBCS? I did submit an RCF for this issue. Maybe someday the idiots in COBOL doc will fix it. Your premise that the users require additional training is patently absurd, as is the suggestion to provide a reference to the COBOL Migration Guide. HTF is anybody supposed to know that this error message was caused by something discussed in the COBOL Migration Guide? We had this same fight with ISPF messages ages ago, and now there's an ISPF messages manual because of it. COBOL should do the same. There, I feel better now. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
In [EMAIL PROTECTED], on 06/22/2005 at 12:41 PM, Perryman, Brian [EMAIL PROTECTED] said: I can't find these blasted messages documented anywhere!! According to IBM the COBOL messages are self explanatory. 1. Sure I'll respect you in the morning. 2. It's okay, Honey, I've had a vasectomy. 3. The check's in the mail. 4. The following messages are self explanatory. The first three are sometimes true. The smart money is against the last. This nonsense has been going on for decades. The ironic thing is that the PL/I messages *are* documented but, the last time that I looked, they were closer to self explanatory than the COBOL messages. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hardware DASD design question.
In [EMAIL PROTECTED], on 06/22/2005 at 08:59 AM, Bill Fairchild [EMAIL PROTECTED] said: IIRC, the 3330 was the first DASD that had skip displacements. My recollection is that the 3340, 3344 and 3350 were the first. I'll have to see whether I still have my 3330 manuals. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 mi gration question (COBOL)
Knowing nothing about DBCS or Unicode I have a silly question - is Unicode a
superset of DBCS? If so, that would explain how you could need to specify 1
or the other, but 1 is required for the other one. Just an uneducated
idea
Rex
-Original Message-
From: Steve Comstock [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 22, 2005 1:36 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4
migration question (COBOL)
Bill Klein wrote:
Steve Comstock [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
snip
And I can't figure out why they made that change,
since DBCS is, supposedly, on its eventual way
out, to be replaced by NATIONAL (Unicode). Any
idea why the default was changed? Especially since
the vast majority of US shops do not even use
DBCS data?
NSYMBOL(National) *requires* (forces on) DBCS, so actually
having/allowing the DBCS option is a pre-requisite for having
Unicode support.
Ah. Now that is just flat out wrong. The doc says it is
NSYMBOL({NATIONAL|DBCS}) - that is, one or the other.
Ahh, but wait. Same doc under Conflicting Compiler Options, it says
NSYMBOL(NATIONAL) forces on the DBCS compiler option. Now I'm really
confused. Why would you set up a choice of
NSYMBOL({NATIONAL|DBCS}) when setting NATIONAL forces on DBCS?
Very nice.
There are some long and painful internal discussions (between myself
and the IBM ANSI COBOL rep) and within the J4 group about exactly what
is Standard conforming behavior when you have control characters
within an alphanumeric literal. I won't go into them here, but I
semi-understand the IBM position that ALLOWING national character
strings within an alphanumeric literal is a good thing when you MAY
use X0E type notation
*if* you want to have those x'0d' and x'0e' within literals.
The change in defaults WAS highlighted in announcements, migration
guides, and installation material - but what its IMPLICATIONS were -
are probably unclear to most programmers (application or systems).
Yup.
Kind regards,
-Steve Comstock
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html
E-MAIL CONFIDENTIALITY USE NOTICE: The contents of this e-mail message and
any attachments are intended solely for the addressee(s) and may contain
confidential and/or legally privileged information. If you are not the
intended recipient of this message or if this message has been addressed to you
in error, please immediately alert the sender by reply e-mail and then delete
this message and any attachments. In addition, you are strictly prohibited
from using, disseminating, distributing, copying, or storing this message and
any attachments.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
I think you're confusing the DBCS value of the NSYMBOL option with the
DBCS option.
Don Imbriale
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of Steve Comstock
Sent: Wednesday, June 22, 2005 2:36 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4
migration question (COBOL)
Bill Klein wrote:
Steve Comstock [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
snip
And I can't figure out why they made that change,
since DBCS is, supposedly, on its eventual way
out, to be replaced by NATIONAL (Unicode). Any
idea why the default was changed? Especially since
the vast majority of US shops do not even use
DBCS data?
NSYMBOL(National) *requires* (forces on) DBCS, so actually
having/allowing
the DBCS option is a pre-requisite for having Unicode support.
Ah. Now that is just flat out wrong. The doc says it is
NSYMBOL({NATIONAL|DBCS}) - that is, one or the other.
Ahh, but wait. Same doc under Conflicting Compiler Options,
it says NSYMBOL(NATIONAL) forces on the DBCS compiler option.
Now I'm really confused. Why would you set up a choice of
NSYMBOL({NATIONAL|DBCS}) when setting NATIONAL forces on DBCS?
Very nice.
There are some long and painful internal discussions (between
myself and
the IBM ANSI COBOL rep) and within the J4 group about exactly what is
Standard conforming behavior when you have control characters
within an
alphanumeric literal. I won't go into them here, but I
semi-understand the
IBM position that ALLOWING national character strings within an
alphanumeric literal is a good thing when you MAY use X0E type
notation
*if* you want to have those x'0d' and x'0e' within literals.
The change in defaults WAS highlighted in announcements, migration
guides,
and installation material - but what its IMPLICATIONS were - are
probably
unclear to most programmers (application or systems).
Yup.
***
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HALON et al
There is also a product called Inergen -- a mixture of 52% nitrogen, 40% argon and 8% carbon dioxide -- that claims to be safe to the environment and people. Ned Hedrick Sr. Mgr., Systems Administration Transaction System Architects, Inc. This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HALON et al
In a message dated 6/22/2005 1:37:48 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Please watch your attributions; I was not the author of the above. Stripping the leading on quoted material is at best misleading. OK. Sorry. Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
Imbriale, Donald (Exchange) wrote:
I think you're confusing the DBCS value of the NSYMBOL option with the
DBCS option.
Well, it certainly is confusing. But I tried to make it
clear what I was saying is choosing the NATIONAL value
for the NSYMBOL option forces on the DBCS option. And
it still doesn't make any sense. Of course, it probably
is not a good practice to have standalone options the
same as choices for other options.
Kind regards,
-Steve Comstock
Don Imbriale
[snip]
NSYMBOL(National) *requires* (forces on) DBCS, so actually
having/allowing
the DBCS option is a pre-requisite for having Unicode support.
Ah. Now that is just flat out wrong. The doc says it is
NSYMBOL({NATIONAL|DBCS}) - that is, one or the other.
Ahh, but wait. Same doc under Conflicting Compiler Options,
it says NSYMBOL(NATIONAL) forces on the DBCS compiler option.
Now I'm really confused. Why would you set up a choice of
NSYMBOL({NATIONAL|DBCS}) when setting NATIONAL forces on DBCS?
Very nice.
There are some long and painful internal discussions (between
myself and
the IBM ANSI COBOL rep) and within the J4 group about exactly what is
Standard conforming behavior when you have control characters
within an
alphanumeric literal. I won't go into them here, but I
semi-understand the
IBM position that ALLOWING national character strings within an
alphanumeric literal is a good thing when you MAY use X0E type
notation
*if* you want to have those x'0d' and x'0e' within literals.
The change in defaults WAS highlighted in announcements, migration
guides,
and installation material - but what its IMPLICATIONS were - are
probably
unclear to most programmers (application or systems).
Yup.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is driver 55k in z machines ?
On Wed, 22 Jun 2005 19:37:03 +0200, R.S. [EMAIL PROTECTED] wrote: Max Scarpa wrote: I'm applying a PSP for a new machine (z890-460). In documentation I found many times references to 'Driver 55K'. As I'm not a z/OS sysprog, can anyone explain me what it is ? A piece of HW ? It is microcode level. Some time ago driver 55 was widely discussed, but nobody could answer how to check the level. ;-))) Now I know: Logon to HMC as SERVICE, choose Console Actions and then choose icon responsible for microcode install/accept/reject. I don't remember the name of the icon, it's on the top of frame. First panel displayed will contain the driver level. You can also sign up for machine information in resource link. Regards, Mark -- Mark Zelden Sr. Software and Systems Architect mailto: [EMAIL PROTECTED] Systems Programming expert at http://Search390.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hardware DASD design question.
In a message dated 6/22/2005 1:37:35 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: My recollection is that the 3340, 3344 and 3350 were the first. I'll have to see whether I still have my 3330 manuals. Could well be. I hesitated on saying 3330. I think the 3340 and 3344 had 3 SDs and the 3350 had 5. Too many decades ago to remember clearly. They always seemed to go up by 2 whenever they increased. 3375/3380/3390s had the most - 7 SDs. The way these worked was pretty clever. The first thing ever permanently recorded on a track is the Home Address. Once skip displacements were invented, the SDs were saved in a normally unreadable part of the Home Address. To read them in or write them back out, you had to use the Read/Write Special Home Address CCW. This read in 27 bytes on the 3375 and 28 on 3380/3390, 14 bytes of which were 7 different 2-byte SDs. Then when you wrote R0 after the HA, the controller copied the 7 SDs that it found in the HA into an unreadable part of R0 (a glorified count field, IIRC). Then whenever you wrote the first record after R0, the controller copied the 7 SDs into an unreadable part of this new record. Thus the same 7 SDs were propagated into each new record written on the track, and no matter where you were on the track when you first established orientation, the controller would have all 7 SDs available the next time it sensed any count field. Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 mi gration question (COBOL)
And apparently succeeded ;~) Thanks for the info. Rex -Original Message- From: Steve Comstock [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 1:55 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 mi gration question (COBOL) Pommier, Rex R. wrote: Knowing nothing about DBCS or Unicode I have a silly question - is Unicode a superset of DBCS? If so, that would explain how you could need to specify 1 or the other, but 1 is required for the other one. Just an uneducated idea Rex Well I know a little about Unicode but hardly anything about DBCS. I do know that IBM created DBCS well before the Unicode standard came about. I don't know if DBCS was ever an official standard supported by some semi-independent standards body or if it was just IBM. I also do not know if the character mappings are even close. I do know that DBCS has this concept of shifting in and out of DBCS mode and Unicode does not do that at all. So it doesn't look like they are particularly related. It looks like IBM was trying to find some way to add Unicode support and retain DBCS support for customers who have been using this for a long time. As the joke goes, They wanted to do this in worst possible way ... Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html E-MAIL CONFIDENTIALITY USE NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. In addition, you are strictly prohibited from using, disseminating, distributing, copying, or storing this message and any attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downgrade 9672
I remnember Texas Tech getting a speed upgrade to there 370/145 back in the 70's. It consisted of the CE removing three loops from the 145's microcode. The price tag for this upgrade? A cool $ 50K! I remember a story from long ago: Honeywell had a processed that came in single and double speeds, with a price jump. If you had the slower processor and paid to upgrade to the faster, the CE removed a jumper that made the clock run at half-speed! I can't swear this was true, could be one of those urban computer myths -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing Little Falls, NJ 07424 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.fdr.innovationdp.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Change control software [for Natural]
Caveat: I get the daily digest so this might already have been suggested... -- At June 21, 2005 14:02, concerning Re: Change control software, Natarajan Mohan [EMAIL PROTECTED] wrote (to Neil Duffee): With respect to the same subject, I would like to know if anybody uses any of these change management packages with NATURAL. Ah! This is a different kettle of fish; provided you mean Natural from Software AG. You'll find the best being N2O from Treehouse Software (www.TreeHouse.com) which is even touted above PAC that is supplied by SAG themselves. We've had N2O from, at least, late 80's and I've heard another client even performs migrations across LPars without complexity or difficulty. You'll get better information/opinions related to Software AG products on [EMAIL PROTECTED] which is an active lively list. There is a web-searchable archive using the same hostname. -- signature = 6 lines follows -- Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee How *do* you plan for something like that? Guardian Bob, Reboot For every action, there is an equal and opposite criticism. Systems Programming: Guilty, until proven innocent John Norgauer 2004 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to know the z/OS version by TSO login.
In ISPF 6, issue the command ISPVCALL STATUS Bo Xie [EMAIL PROTECTED] wrote:Hi, Someone told me to type in D IPLINFO in master console to know the z/OS version. But I can not touch the master console and get the following errors by TSO login: - READY D IPLINFO IKJ56500I COMMAND D NOT FOUND READY /D IPLINFO IKJ56621I INVALID COMMAND NAME SYNTAX READY - How to know the z/OS version by TSO login? Thank you! Best Regards, Xie Bo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Discover Yahoo! Find restaurants, movies, travel more fun for the weekend. Check it out! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IPLINFO exec alter ego
Hi, I know there are many users of my IPLINFO exec that monitor this list so I thought I would post some news about a new feature. After a recent thread on ISPF-L, I updated IPLINFO to have an alter ego as a REXX function. The function execution format can be used to retrieve up to 10 variables that are used in the exec. This could be useful in other rexx code instead of having to copy IPLINFO code snippets into it (I know others that have done this and I have done it as well). For example, the subject of writing a one line message to a data set about IPL information was mentioned to me recently. It can now be done easily using IPLINFO like this: /* REXX */ /* one liner IPL information using IPLINFO rexx function */ IPL_SUMMARY = Iplinfo(VAR,ipldate,ipltime,iplvol,ipladdr,iplparm) say IPL_SUMMARY result: 06/12/2005 02:06:26 RESD10 D000 700AD0M1 OR /* REXX */ /* one liner IPL information using IPLINFO rexx function */ IPL_SUMMARY = Iplinfo(VAR,ipldate,ipltime,iplvol,ipladdr,iplparm) parse var IPL_SUMMARY ipldate ipltime iplvol ipladdr iplparm say 'Date:'ipldate 'Time:'ipltime 'Vol:'iplvol , 'Load addr:'ipladdr 'LOADPARM:'iplparm result: Date:06/12/2005 Time:02:06:26 Vol:RESD10 Load addr:D000 LOADPARM:700AD0M1 If interested the updated IPLINFO version is on my web site now and should be on the CBT updates page in the near future. Cheers, Mark -- Mark Zelden Sr. Software and Systems Architect mailto: [EMAIL PROTECTED] Systems Programming expert at http://Search390.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hardware DASD design question.
In a message dated 6/22/2005 2:46:21 P.M. Central Standard Time, [EMAIL PROTECTED] writes: couple of devices/controller types, and is no longer documented. It would let you read ALL the bytes on the track, including the inter-record gaps and all these SDs, inter alia. But what you read in was not much fun to decipher by hand and eyeball. Under MFT there was bug in OPEN that positioned you at CC HH 00 00 if you did a rewind before open. The IBM PSR poo-pooed the observation with something like-NFWIMLT! Next day came to work to find his test GIS pack relabeld with his INITIALs iiiYTI(yes there is!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
OK, to explain ... *ALL* the DBCS (or NODBCS) compiler option does is to determine how X'0E' and X'0D' are treated when they appear WITHIN an alphanumeric literal. When it is turned on, then they are treated as SHIFT-OUT/IN control characters (and this may be shifting to Unicode *or* to IBM-specific-DBCS codes). The NSYMBOL compiler option determines - What the default USAGE is for PIC N data items (NATIONAL (aka UNICODE) or DISPLAY-1 (aka DBCS)) - Whether Nliterals (and NXliterals are DBCS or UNICODE format (on output) Therefore, it is logically possible to have any combination of NODBCS/DBCS and NSYMBOL(NATIONAL)/(DBCS). IBM, however, at roughly the same time they changed the default to DBCS decided (for political reasons - I believe, not syntactic reasons) NOT to support the combination of NODBCS ,NSYMBOL(NATIONAL) Clearer -- Bill Klein wmklein at ix.netcom.com Steve Comstock [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Imbriale, Donald (Exchange) wrote: I think you're confusing the DBCS value of the NSYMBOL option with the DBCS option. Well, it certainly is confusing. But I tried to make it clear what I was saying is choosing the NATIONAL value for the NSYMBOL option forces on the DBCS option. And it still doesn't make any sense. Of course, it probably is not a good practice to have standalone options the same as choices for other options. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downgrade 9672
... If you had the slower processor and paid to upgrade to the faster, the CE removed a jumper that made the clock run at half-speed! I can't swear this was true, could be one of those urban computer myths ... I saw it happen on a Honeywell Level 66, in the late 1970's. This was at the University of Waterloo and if I'd not been there, I would probably not have believed it. -teD (The secret to success is sincerity. If you can fake that, you've got it made!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
Bill Klein wrote: OK, to explain ... *ALL* the DBCS (or NODBCS) compiler option does is to determine how X'0E' and X'0D' are treated when they appear WITHIN an alphanumeric literal. When it is turned on, then they are treated as SHIFT-OUT/IN control characters (and this may be shifting to Unicode *or* to IBM-specific-DBCS codes). The NSYMBOL compiler option determines - What the default USAGE is for PIC N data items (NATIONAL (aka UNICODE) or DISPLAY-1 (aka DBCS)) - Whether Nliterals (and NXliterals are DBCS or UNICODE format (on output) Therefore, it is logically possible to have any combination of NODBCS/DBCS and NSYMBOL(NATIONAL)/(DBCS). IBM, however, at roughly the same time they changed the default to DBCS decided (for political reasons - I believe, not syntactic reasons) NOT to support the combination of NODBCS ,NSYMBOL(NATIONAL) Clearer Yup. Thanks. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downgrade 9672
IIRC hearing the same about the Series 6000 the Los Angeles Community College District (where I both studied and worked) had. (Replaced a perfectly good 370/158. Long political story.) Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.mrmullins.big-bear-city.ca.us/ http://www.the-bus-stops-here.org/ -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Wednesday 22 June 2005 12:33 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Downgrade 9672 I remnember Texas Tech getting a speed upgrade to there 370/145 back in the 70's. It consisted of the CE removing three loops from the 145's microcode. The price tag for this upgrade? A cool $ 50K! I remember a story from long ago: Honeywell had a processed that came in single and double speeds, with a price jump. If you had the slower processor and paid to upgrade to the faster, the CE removed a jumper that made the clock run at half-speed! I can't swear this was true, could be one of those urban computer myths -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to know the z/OS version by TSO login.
If you use ISPVCALL you need to enter it twice. The first execution collects the data and the second displays the output. Lizette Koehler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISKE/IVSK
I'm looking for advice on the use of IVSK / ISKE instructions, IVSK is a fine righteous thing to play with. ISKE is not. I have this program that loads (SVC 08) a couple of programs. The program that load is running key9 , however SVC08 load them in key8 with fetch protection... Contents supervision is only ever going to load the module in fetch protected storage in the job step key unless the module is reentrant and comes from an APF authorized library. Them's the rules. So in this case, there is no way for you to get what you want playing by the rules. That's usually a clue that what you think you want is not really what you want at all. I'm trying to turn off the fetch protect bit with sske OOOHH... Tres bad idea. SSKE is one of those instructions that are reserved for use by the control program and in any case it only changes the real storage key. You would just break things if you ever got that to work. A key zero and sup state program can use the CHANGKEY macro to change the virtual storage key and fetch protection, but the area has to begin on a page boundary and contain an integral number of pages. Beware that contents uses subpool 251/252 for program loads and it just getmains as much as it needs for the module, so you have no control over alignment and number of pages unless you put the right directives in the bind for the module. You would have to get the origin and length of the module by calling CSVQUERY first. IMO even that is kind of dangerous, but if you have no other choice fire away. Its not my dog. when I run IVSK and ISKE I get different key. The program thats read the storage is a CICS program. I pass to ISKE the real address which I obtain from LRA. Ignoring for a moment how you manage to issue an LRA from a normal unauthorized, problem state key 8/9 CICS program, there is no way to guarantee that the virtual to real mapping is the same between the LRA (which should be a LRAG anyway) and the ISKE. You would have to page fix the storage first which is a bit on the brutal side. In addition, ISKE is sensitive to the virtual addressing mode. If you are in 31 bit mode its only going to look at the 31 bit portion of the real address, even if there's non-zero data in the high half of the gpr. This is a place you really should not be treading. It makes me wonder if CICS is turning on / off the fetch protect bit because I trace with CEDF I can browse the loaded program but can't run the user program. AFAIK CICS doesn't do anything of the sort. The storage protection override control feature of the architecture allows any key 8 program to access key 8 or key 9 data, but not the reverse. CEDF is in key 8 so no harm no foul. Your application is (apparently) in key 9. Bzzzt. I'm not sure what you're trying to accomplish. Since you're talking about supervisor state instructions, you probably have the wherewithall to get more or less anythign you want. Figuring out what you want is going to be the hard part. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 mi gration question (COBOL)
In [EMAIL PROTECTED], on 06/22/2005 at 01:40 PM, Pommier, Rex R. [EMAIL PROTECTED] said: Knowing nothing about DBCS or Unicode I have a silly question - is Unicode a superset of DBCS? No; Unicode is a 20-bit code with a 16-bit subset, compatible with ISO 10646, and does not use a SI/SO mechanism. There is a transform (UTF-8) for representing Unicode in 8-bit bytes, but it does not use SI/SO either. Note: the first half page (code points 0-127) of Unicode are identical to ASCII. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help on SC03 abend
In [EMAIL PROTECTED], on 06/22/2005 at 12:11 PM, Kok, Howi [EMAIL PROTECTED] said: I'm not sure if I should post this in this list. Yes; it's the most appropriate list for your question. I'm not sure if I should post this in this list. Anyway, I hope some of you can help me out. We have a batch DB2 COBOL program PGMA that calls an assembler program PGMB to open, read, and close four VSAM files. I don't know why PGMB closes only two of the files. PGMB is broken. Instead of trying to live with the bug, why not try to get it fixed? Upon PGMA termination we would get SC03 abends with messages IEC999I IFG0TC0A,IFG0TC0B,jobname,stepname,DEB ADDR = debaddr,DSN = VSAM data set name for the two closed files. ITYM for the two files that are not closed. According to the programmer there is no problem when the PGMB is called from a non-DB2 COBOL program. He's mistaken. What should be done differently when the assembler program is called from a DB2 COBOL program? Nothing in this case. Should we not close any files and let the system detect the DEBs and close them? No, PGMB should close all files that it opens. If the programmer refuses to do so, discuss it with your and his management. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
FW: (Fwd) RE: Change control software [for Natural]
Actually, I meant to forward to the list -Original Message- From: Neil Duffee [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 3:34 PM To: Natarajan Mohan Cc: Gibney, Dave Subject: (Fwd) RE: Change control software [for Natural] Natarajan: I expect that Dave really meant this for you as the originator. --- Forwarded message follows --- Subject: RE: Change control software [for Natural] Date sent:Wed, 22 Jun 2005 14:52:14 -0700 From: Gibney, Dave [EMAIL PROTECTED] To: [EMAIL PROTECTED] And if you ask over on Sag-l, maybe Darrel will describe how we do Natural and Endevor. And there's stuff in the archives. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Neil Duffee Sent: Wednesday, June 22, 2005 12:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Change control software [for Natural] Caveat: I get the daily digest so this might already have been suggested... -- At June 21, 2005 14:02, concerning Re: Change control software, Natarajan Mohan [EMAIL PROTECTED] wrote (to Neil Duffee): With respect to the same subject, I would like to know if anybody uses any of these change management packages with NATURAL. Ah! This is a different kettle of fish; provided you mean Natural from Software AG. You'll find the best being N2O from Treehouse Software (www.TreeHouse.com) which is even touted above PAC that is supplied by SAG themselves. We've had N2O from, at least, late 80's and I've heard another client even performs migrations across LPars without complexity or difficulty. You'll get better information/opinions related to Software AG products on [EMAIL PROTECTED] which is an active lively list. There is a web-searchable archive using the same hostname. --- End of forwarded message - signature = 6 lines follows -- Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee How *do* you plan for something like that? Guardian Bob, Reboot For every action, there is an equal and opposite criticism. Systems Programming: Guilty, until proven innocent John Norgauer 2004 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help on SC03 abend
If my old addled brain is thinking correctly, I believe over 10 years ago IBM decided to no longer be nice to programs and require that all programs close any files they open. And if they did not close them, the system would then issue a SC03 abend. Or am I getting too forgetful??? Lizette Koehler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 22, 2005, at 5:34 PM, Ed Gould wrote: I will go for it hey its almost Friday. If you can't figure out what the message is saying open a PMR with the COBOL people tell them for the up teenth time that these messages are NOT self describing. Ed IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. A shift-out without a shift-in? Pretty obvious. IGYPS0158-E A nonnumeric or national literal containing double- byte characters was found which exceeded the maximum literal length or reached end of area B before terminating. A literal delimiter was placed at column 72 of line And you forgot to terminate or continue in accordance with the rules. What is not self describing about these? There are plenty of things to complain about with IBM's Cobol implementation -- but their error messages are pretty good. Perhaps even self-describing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
Joe Zitzelberger wrote: On Jun 22, 2005, at 5:34 PM, Ed Gould wrote: I will go for it hey its almost Friday. If you can't figure out what the message is saying open a PMR with the COBOL people tell them for the up teenth time that these messages are NOT self describing. Ed IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. A shift-out without a shift-in? Pretty obvious. Not if he was not using DBCS. No reason to expect this message. Apparently it was caused by the change if default compiler option settings, which does seem a little obscure, don't you think? IGYPS0158-E A nonnumeric or national literal containing double- byte characters was found which exceeded the maximum literal length or reached end of area B before terminating. A literal delimiter was placed at column 72 of line And you forgot to terminate or continue in accordance with the rules. What is not self describing about these? There are plenty of things to complain about with IBM's Cobol implementation -- but their error messages are pretty good. Perhaps even self-describing. Well, I'll be happy to concede they are pretty good most of the time. And I know they do work on improving them regularly. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help on SC03 abend
Generally you can get away with not closing DCBs and the system will close them. The problem occurs when the DCB is either in GETMAINed storage, or in a secondary load module brought in by the jobstep program with a LOAD (which is pretty much the same thing) - AND the storage gets freed before end of jobstep. MVS goes to close the DCB and - ta-da! - it's not there. SC03 will also happen if a DCB gets overlaid or clobbered in some way before the system can close it. I think that a job's behavior in this regard can be a little unpredictable because things may depend on whether the storage gets reused or not. That's probably why he is seeing different results depending on whether or not DB2 is in the picture. It's not DB2 per se, but the fact that DB2 coincidentally changes the storage allocation picture in some way. He might get different results, for example, with a different region size. Shmuel is 100% correct though - it's like your mom said: if you open the DCB, you close it. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Wednesday, June 22, 2005 3:55 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Help on SC03 abend If my old addled brain is thinking correctly, I believe over 10 years ago IBM decided to no longer be nice to programs and require that all programs close any files they open. And if they did not close them, the system would then issue a SC03 abend. Or am I getting too forgetful??? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 22, 2005, at 7:04 PM, Steve Comstock wrote: Joe Zitzelberger wrote: On Jun 22, 2005, at 5:34 PM, Ed Gould wrote: I will go for it hey its almost Friday. If you can't figure out what the message is saying open a PMR with the COBOL people tell them for the up teenth time that these messages are NOT self describing. Ed IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. A shift-out without a shift-in? Pretty obvious. Not if he was not using DBCS. No reason to expect this message. Apparently it was caused by the change if default compiler option settings, which does seem a little obscure, don't you think? Not at all. Just because you find a shift-in in your source doesn't mean the error message is at fault. If you look at your listing and actually see a shift in there, then you might want to complain about the preprocessor that placed it there. But that would be the preprocessors fault, not the message -- it means exactly what it says. If you will pardon the pun, this sound like a perfect example of 'shooting the messenger' instead of addressing the root cause. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISKE/IVSK
At first LOAD (SVC 08) is a NONO under CICS as in case of transactions abends nobody will ever free the storage for this prog. Look at the CICS API Exec Cics Load command. CICS will then LOAD the program depending on the RENT,RMODE into the RDSA, SDSA, ERDSA or ESDSA. The Exec Cics will give you back the entrypoint and now it's a simple BALR R14,R15 (assume same mode). I don't understand your request! Roland -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Im Auftrag von Richard Verville Gesendet: Mittwoch, 22. Juni 2005 20:19 An: IBM-MAIN@BAMA.UA.EDU Betreff: ISKE/IVSK I'm looking for advice on the use of IVSK / ISKE instructions, I have this program that loads (SVC 08) a couple of programs. The program that load is running key9 , however SVC08 load them in key8 with fetch protection... I'm trying to turn off the fetch protect bit with sske but when I run IVSK and ISKE I get different key. The program thats read the storage is a CICS program. I pass to ISKE the real address which I obtain from LRA. It makes me wonder if CICS is turning on / off the fetch protect bit because I trace with CEDF I can browse the loaded program but can't run the user program. Any ideas richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HALON et al
This is attributable to me, for the record. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.) Sent: Wednesday, June 22, 2005 11:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: HALON et al In [EMAIL PROTECTED], on 06/22/2005 at 09:03 AM, Bill Fairchild [EMAIL PROTECTED] said: In a message dated 6/22/2005 7:24:23 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Not true, I've been in 3 HALON dumps back in the days it was THE method for computer room FS. One must exit quickly as it will make you short of breath at high enough concentrations since it displaces oxygen. Please watch your attributions; I was not the author of the above. Stripping the leading on quoted material is at best misleading. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What's the 2nd level system for z/VM or z/OS?
On 6/22/05, Gabriel Tully [EMAIL PROTECTED] wrote: Yes, 2nd level refers to z/OS running as a guest under z/VM Thank you very much for your reply! Is there any reference for 2nd level? I want to copy in/out some files between the host z/VM and the guest z/OS, but don't know how to do it! Best Regards, Xie Bo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IBM-MAIN@BAMA.UA.EDU IBM-MAIN@BAMA.UA.EDU
Does anyone have any experience with 3494-B20 microcode level R7.4? Regards, Bil McKinley SLF Consulting Services, inc. 67 Wall St Ste 2211-0094 New York, NY 10005 t/ 212.945.0062 m/ 917.224.6012 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Downgrade 9672
I remember the 'go-faster' stripes that Burroughs had to put on the B2700 after 'upgrading ' it from a B2500. I beleive this was needed to convince the Customer that he had actually got something for his (quite a lot of) money. this upgrade was really little more than a jumper chjange clock speed increase also. I also remember that a 600 cards-per-minute 2501-001 card reader could be upgraded to a 2501-002 (1100 cards-per-minute) by the replacement of a different sized gear wheel. If you owned ( and maintained) the machine , no-one could stop you! I always imagined that IBM's 'Licenced Internal Code' ( not to mentioned Graduated licnening charges, of course!) was a way to protect them from any one else being able to undo a 'Kneecapped' processor nowadays. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Wednesday 22 June 2005 12:33 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Downgrade 9672 I remnember Texas Tech getting a speed upgrade to there 370/145 back in the 70's. It consisted of the CE removing three loops from the 145's microcode. The price tag for this upgrade? A cool $ 50K! I remember a story from long ago: Honeywell had a processed that came in single and double speeds, with a price jump. If you had the slower processor and paid to upgrade to the faster, the CE removed a jumper that made the clock run at half-speed! I can't swear this was true, could be one of those urban computer myths -- This message and any attachment is intended for the use of the individual or entity to whom it is addressed by the first sender and contains information which may be confidential and/or privileged. If you receive this message and any attachment in error, delete it immediately and notify the sender by email or phone +612 9218 1000 Unless you have been expressly authorised by the sender, you are prohibited from copying, distributing or using the information contained in this message and any attachment Tabcorp Holdings Ltd(ABN 66 063 780 709)and its related bodies corporate Tabcorp is not responsible for any of the changes made to this message or any attachment other than those made by Tabcorp, or for the effect of changes made by others on the meaning of this message and any attachment Tabcorp does not represent that any attachment is free from computer viruses or defects and the user assumes all responsibility for any loss or damage resulting directly or indirectly from the use of any attachment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
3494-B20 new microcode R7.4 experience?
Does anyone have any experience with 3494-B20 microcode level R7.4? Regards, Bil McKinley SLF Consulting Services, inc. 67 Wall St Ste 2211-0094 New York, NY 10005 t/ 212.945.0062 m/ 917.224.6012 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Testing symbols with JCL IF
I got frustrated at the inability to test anything other than return codes the like with JCL IF. Maybe I'm re-inventing the wheel here, but I wrote a little Rexx script that reduced my frustration. INTERP interprets the value of its argument and returns the result as its return code. So you can for example say //INT1 EXEC PGM=INTERP,PARM='DSP = SHR' // IF INT1.RC = 1 THEN whatever you want to do if DSP was SHR. // ENDIF It should handle Rexx expressions up to 100 characters of any complexity, with parentheses, numeric calculations, etc., that return either a truth (1 or 0) or numeric result. Here is how to execute it if you don't have the Rexx compiler: //INT1 EXEC PGM=IRXJCL,PARM='INTERP DSP = SHR ' //SYSEXEC DD DSN=your.rexx.library,DISP=SHR Here is the Rexx source code: /* Interp: Rexx to set return code by interpreting parm */ /* Returns the value obtained by interpreting its argument, with the following special values: 4095 = Rexx Syntax error 4094 = Non-numeric result 4093 = Result out of range 0 to 4095 */ Signal On Syntax Name SyntaxErr Interpret ttt = Arg(1) If Datatype(ttt) \= NUM Then Exit 4094 If ttt = 4095 ttt = 0 Then Exit ttt Exit 4093 SyntaxErr: Exit 4095 I hereby place this code in the public domain. Feedback appreciated. Charles Mills -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMS report
Hi all, Do you have some idea of how to obtain PDS directory information using batch job? And another question: how to obtain the %used of a whole storage group? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
- Original Message - From: Joe Zitzelberger [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, June 22, 2005 7:58 PM Subject: Re: Another OS/390 to z/OS 1.4 migration question (COBOL) On Jun 22, 2005, at 7:04 PM, Steve Comstock wrote: IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. A shift-out without a shift-in? Pretty obvious. Not if he was not using DBCS. No reason to expect this message. Apparently it was caused by the change if default compiler option settings, which does seem a little obscure, don't you think? Not at all. Just because you find a shift-in in your source doesn't mean the error message is at fault. If you look at your listing and actually see a shift in there, then you might want to complain about the preprocessor that placed it there. But that would be the preprocessors fault, not the message -- it means exactly what it says. If you will pardon the pun, this sound like a perfect example of 'shooting the messenger' instead of addressing the root cause. Joe, You are wrong here. Imagine a shop that has used COBOL for decades, and can't even spell DBCS. All of a sudden this message pops up after a compiler upgrade. The programmer asks What's a shift-in? The systems programmer says BTF outta me. Let's get the message manual. Oops, no manual, now what? Open a PMR only to be told by COBOL Level 2 what an idiot you are.. Your assumption that this message tells the whole story is absurd. Every IBM message is supposed to have a response documented, like this: Programmer response: If using DBCS support, be sure that your DBCS character stream contains proper shift-in shift-out pairs. If you are not using DBCS, be sure that you specify the NODBCS in your compile. Problem solved. Expecting the user to know every option and feature of the COBOL compiler, especially those features and options that they're not even using, is ridiculous. That's why every error message generated by an IBM product is supposed to be fully documented with appropriate Response sections. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
