Re: REXX question
Lizatte, I don't think TSO-REXX is active any more... Itschak On Sat, Oct 4, 2008 at 4:23 PM, Lizette Koehler [EMAIL PROTECTED]wrote: Rexx is case sensitive. Use PARSE Pull UPPER Answer Then it will always be upper case and a test for Upper Case letters/words will work. Lizette PS. You may wish to join the TSO-REXX newsgroup. For TSO-REXX subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO TSO-REXX hi I make this: do until answer = N' instructions say 'Do you want to exit? (s/n)' pull answer if answer = 'S' then exit end I type s, but not exit of the do until?? Why?? this is a case sensitive?? It´s correct?? more a question: how i do to treat for error: 10 +++ dec25 = date(B,year1225,S)//7 IRX0040I Error running CHRISTMA, line 10: Incorrect call to routine the error ocorred when typed less four digits to year?? ex: year with tree or two or one digits 200 or 20 or 2. 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 -- 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: REXX question
Actually TSO-REXX at Marist college is very active, that is unless it has died over the last couple of days. It is one of those newsgroups that does spurts. Some days we are very active and others, not so much. Check it out. We have a lot to say and discuss about REXX on that newsgroup. Lizette Lizatte, I don't think TSO-REXX is active any more... -- 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: LE question about COBOL compatibility
Mark Yuhas wrote: The reason why some shops (mine, in particular) are still using OS/VS COBOL and VS COBOL II is that decisions were made according to expediency and the fact that the mainframe was to be obsolete by the year 2000. Ergo, no need to convert. On January 1, 2009, we, the mainframers, will be celebrating our 10th year of obsolescence with many more in sight. If it weren't for CICS DB2, the conversion to Enterprise COBOL would have been delayed until LE would not support the old COBOL run time environments. Furthermore, the conversion to Enterprise COBOL has been pared back to only those programs using CICS and/or DB2. Mark, Is there anyone in managment there who sees the irony in all this? If there is someone who might have an open mind, I've got a series of VSPs (Very Short Presentations) about today's mainframes, at: http://www.trainersfriend.com/General_content/VSP_site.htm No charge, no registration. If you think they might at least open the door a bit more, feel free to use them. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.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: History question: //SYSABOUT DD statement
Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown On Tue, 30 Sep 2008 14:53:12 -0500, Chase, John wrote: Hi, All, I can't remember what the //SYSABOUT DD statement was for (doing a little cleanup here). Didn't it have something to do with OS/VS COBOL? Or was it long-ago MVS-specific? We seem to have more than a few of them.. I found a reference to it in VS COBOL II: Application Programming Guide for MVS and CMS. Ah! I missed it by a whole version. Still obsolete in our LE/COBOL environment, though. Thanks. -jc- If you have JCL occurrences of SYSABOUT, you may also have occurrences of SYSDBOUT. Both were COBOL-required DD names for pre-LE COBOL runtime environment and obsolete under LE as things that went to these datasets go to CEEDUMP and SYSOUT under LE. The LE runtime will dynamically allocate the DDs it requires if needed, but if you want better control over the output queue properties for exceptional diagnostic output you may want to be sure the LE counterparts are defined in JCL for COBOL execution steps when you delete the obsolete DDs. For example, we do long-term archival of job logs and typical job-step output, and that may be the default OUTPUT statement attributes. Default long-term archival of a 100,000 line diagnostic dump from a job-step failure would rarely be appropriate! -- 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
VSAM I/O
I am looking for the simplest way to intercept/modify an i/o for a VSAM data set without impacting the application. All suggestions are welcome. Rob Schramm -- 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: VSAM I/O
Rob, What is it that you don't like about this VSAM I/O? Or what is it that you want to do with it? Allow it? Disallow it? Modify it? Add buffers for performance? You're going to have to tell us a little more about your problem, so we can come up with a good answer. Regards, Ulrich Krueger -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rob Schramm Sent: Sunday, October 05, 2008 09:54 To: IBM-MAIN@BAMA.UA.EDU Subject: VSAM I/O I am looking for the simplest way to intercept/modify an i/o for a VSAM data set without impacting the application. All suggestions are welcome. Rob Schramm -- 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: VSAM I/O
In a message dated 10/5/2008 11:55:34 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: I am looking for the simplest way to intercept/modify an i/o for a VSAM data set without impacting the application. I only know of one way to intercept/modify an I/O of any kind, and it is not simple. You must insert a front-end for an IOS module that is involved with the normal processing of an I/O request before it is started with the SSCH instruction. There are several different modules from which you could choose, but in all cases this is an extremely non-trivial task, your code that inserts the front-end must be authorized, and your code that runs when the I/O is intercepted must be bullet-proof with industrial-strength recovery. If you are not faint-hearted and have a sandbox system that you can crash at least 20 times, email me offline for further enlightenment. And intercepting the I/O is an order of magnitude easier than modifying it once intercepted. The reason that modifying it is so hard is because of the vast complexity of DASD channel programs, all possible variations of which your code must support. Bill Fairchild Rocket Software **New MapQuest Local shows what's happening at your destination. Dining, Movies, Events, News more. Try it out! (http://local.mapquest.com/?ncid=emlcntnew0001) -- 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: VSAM I/O
On Sun, 5 Oct 2008, Rob Schramm wrote: I am looking for the simplest way to intercept/modify an i/o for a VSAM data set without impacting the application. All suggestions are welcome. Rob Schramm What occurs to me is to hook OPEN. If the dataset is one that you want to intercept, then put your own I/O routine address into the ACB. That way the VSAM I/O instructions will go to your routine. Another possibility is something like BLSR. Make your own subsystem. Have the step have two DD statements. The one that they OPEN would you the one with your subsystem allocated to it. The other DD would have the actual DSN. When they OPEN your subsystem DD, you open the associated DD. They do I/O which goes to your subsystem. It can then do whatever processing it wants to against the associated DD for whatever request came in from the program. Hope this makes sense. Look at the doc how how BLSR works. -- Q: What do theoretical physicists drink beer from? A: Ein Stein. Maranatha! John McKown -- 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: VSAM I/O
The simplest way is to purchase a product. It depends on what you want to do with the IO. If you want to re-direct it to other DB, you may find VS/2 (Circle) that does that. There are other products that does that, but VS/2 is the common one. Itschak On Sun, Oct 5, 2008 at 6:53 PM, Rob Schramm [EMAIL PROTECTED]wrote: I am looking for the simplest way to intercept/modify an i/o for a VSAM data set without impacting the application. All suggestions are welcome. Rob Schramm -- 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: LE question about COBOL compatibility
I think that the technical people do get it, but management does not - or they just don't care. And the customers - with management feeding them the mainframe is obsolete kool aid, it's no wonder that they think they have to move off to a 'newer' platform. Thanks for the VSPs, I read through most of them and like them. I will try to share them and see if they help. Thanks, Linda Mooney -- Original message -- From: Steve Comstock [EMAIL PROTECTED] Mark Yuhas wrote: The reason why some shops (mine, in particular) are still using OS/VS COBOL and VS COBOL II is that decisions were made according to expediency and the fact that the mainframe was to be obsolete by the year 2000. Ergo, no need to convert. On January 1, 2009, we, the mainframers, will be celebrating our 10th year of obsolescence with many more in sight. If it weren't for CICS DB2, the conversion to Enterprise COBOL would have been delayed until LE would not support the old COBOL run time environments. Furthermore, the conversion to Enterprise COBOL has been pared back to only those programs using CICS and/or DB2. Mark, Is there anyone in managment there who sees the irony in all this? If there is someone who might have an open mind, I've got a series of VSPs (Very Short Presentations) about today's mainframes, at: http://www.trainersfriend.com/General_content/VSP_site.htm No charge, no registration. If you think they might at least open the door a bit more, feel free to use them. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four == == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.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 -- 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: VSAM I/O
Ulrich, I want to modify it before the original caller sees it. Additionally, if they update or write a new record.. I am looking to modify what gets written. I had considered the VSAM special processing exit, but I don't think it will do what I want. I had haven't contacted IBM yet. I thought I would digest suggestions from IBM-Main before continuing down this path. I am not looking for performance or security, just to be able to look at it .. then decide to modify it or not. Thanks, Rob -- 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: LE question about COBOL compatibility
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 10/04/2008
07:41:19 PM:
IMHO, the only reasonable excuse for keeping OS/VS Cobol around is
not having the source code to recompile.
Unfortunately, that is a common problem.
Even IBM has source code that doesn't match object code.
Can you say IEBCOPY boys girls?
-
Too busy driving to stop for gas!
I am not sure what you are suggesting. The compile/assembly dates
in the eyecatchers of the modules would suggest that IBM has source
code which matches this object code.
BROWSESYS1.LINKLIB(IEBCOPY)
Command ===
***
.Ø.0IEBCFAMS..ŵCALLFAMS.._ìIEBCFIO
.Ø.0IEBDSTOC..ùÃIEBDSCOT..ú.IEBCOMC
.Ø.0IEBRSAM ...Ç...yIEBSCN IEBVCT
.Ø.0IEBDSCGI..ê;...$IEBDSCNC...üIEBDSCN
.Ø.0IEBWSAM1..üIEBDSPRM..ßçIEBDSOP
.Ø0OUTD$C ...åLOADD$C ...åUNLDD$C
.Ø...$.0IEBDSCP2..çIEBCDUMPIEBDV0S
س.
Ø..5695PMB01 |.Áë|
Ød
.ŵ.å.-.!.½.Å...ç...$. .á.
...
...Ö...Q...ü...æ...µ...u...y...
...Y...y...Ð...^...
...Ö...È...Ø...ð...
...^..ŵ .Ñ..å.æ...µ...u...y...^...©...
å00..IEBCFAMS20080414HDZ1A10 NONE20.38 .°
...Ö..?u..
...Ø..}Q .--..ÐU..ÐY..ÐÖ..Ð0..Ð4..Ð8..Ð
å00..IEBDSWCP20080414HDZ1A10 NONE20.39 .°
...}..ùÌ..ú8..Y{..YH..YM.ÂY
. ...8...y...½...
å00..IEBVCT 20080414HDZ1A10 NONE20.41 .°
... ..'ø ./ ..ñì..ñÈ..ñÌ..é{..éD..é
å00..IEBCMSG120080414HDZ1A10 NONE20.38 ..
..ú^ ..Q..'^..'©..'½..'¯..'{..'D..'
å00..IEBPRINT20080414HDZ1A10 NONE20.39 .°
..Yh..YU..Z...Z...Z'..Y
..0. ..Ø...Ø
å02ìå00¶.IGG019S920080414HDZ1A10 NONE21.11
...
å00©.IGG019C920080414HDZ1A10 NONE21.10 ..
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
--
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: LE question about COBOL compatibility
I am not sure what you are suggesting. The compile/assembly dates in the eyecatchers of the modules would suggest that IBM has source code which matches this object code. When we converted to XA in the early 1980's, I was at a presentation given by an IBM Canada rep. He said two things: 1. IEBCOPY was still overlays. 2. They had to re-write it, because they lost the source code. I cannot remember his name. - Too busy driving to stop for gas! -- 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
