Re: EXTERNAL: Compiling CICS COBOL 6 Programs with No EXEC CICS Commands
If you use DYNAM, then all programs and sub-programs must reside in a LOAD Library that's concatenated to CICS under DFHRPL. Thanks, Tom -Original Message- From: IBM Mainframe Discussion List On Behalf Of esst...@juno.com Sent: Thursday, February 25, 2021 4:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: Compiling CICS COBOL 6 Programs with No EXEC CICS Commands CAUTION: This email originated from outside of the company. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello, . We are beginning to migrate our CICS V5.4 COBOL programs to COBOL 6. . I need some clarification on compiling CICS COBOL 6 Programs without a Translator. These programs DO NOT contain any EXEC CICS commands and are invoked via a CALL statement and NOT an EXEC CICS LINK. . In this scenario should these CICS COBOL 6 programs be compiled with the DYNAM OR NODYNAM Cobol 6 option. These programs do not get compiled with a CICS Translator. . Paul D'Angelo . . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using BSAM with large block interface
VB without LBI this would not apply. F, FB, or VB with LBI this would apply. On Fri, Feb 26, 2021 at 4:01 PM Joseph Reichman wrote: > > Thank you I’m using VB > > > > > On Feb 26, 2021, at 4:36 PM, Mike Schwab wrote: > > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/len99.htm#len99 > > > > Undefined-length records when using LBI or for fixed-length blocked: > > The method described in the following paragraphs can be used to > > calculate the block length. You can use this method with BSAM, BPAM, > > or BDAM. (It should not be used when using chained scheduling with > > format-U records. In that case, the length of a record cannot be > > determined. > > > > After issuing the CHECK macro for the DECB for the READ request, but > > before issuing any subsequent data management macros that specif > > > > If you are using LBI for BSAM or BPAM, subtract 12 from the address of > > the status area. This gives the address of the 4 bytes that contain > > the length of the block read. > > > >> On Fri, Feb 26, 2021 at 3:00 PM Joseph Reichman > >> wrote: > >> > >> Hi > >> > >> If I code a DCBE and specify a large block interface > >> Larger than that allowed on the DCB > >> > >> Would anyone know after the I/o is complete > >> His many bytes are actually read > >> > >> Thanks > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > > -- > > Mike A Schwab, Springfield IL USA > > Where do Forest Rangers go to get away from it all? > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
On 2/26/2021 2:36 PM, Tony Harminc wrote: sort of the vi of TSO ... You take that back!! :) Sorry... I just used vi a minute ago and although I finally remembered shift-g to move to the bottom, I had to goggle how to move back to the top. gg Of course! It's so obvious. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
March 1971 is almost 50 years ago. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tony Harminc [t...@harminc.net] Sent: Friday, February 26, 2021 6:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler - Authorized program debug On Fri, 26 Feb 2021 at 18:37, Seymour J Metz wrote: > > > 40 years ago > ? I said "(well, TEST, but the syntax is identical)". And yes, I realize that each has an only overlapping set of subcommands and functions. > TEST is older older and TESTAUTH is more recent. Indeed. But not all *that* much more recent. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
On Fri, 26 Feb 2021 at 18:37, Seymour J Metz wrote: > > > 40 years ago > ? I said "(well, TEST, but the syntax is identical)". And yes, I realize that each has an only overlapping set of subcommands and functions. > TEST is older older and TESTAUTH is more recent. Indeed. But not all *that* much more recent. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
> 40 years ago ? TEST is older older and TESTAUTH is more recent. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tony Harminc [t...@harminc.net] Sent: Friday, February 26, 2021 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler - Authorized program debug On Fri, 26 Feb 2021 at 02:46, Tom Brennan wrote: > > Is the TSO TESTAUTH command still around? I have to admit I can't > remember ever trying it. It's still there, and works much the way it did 40 years ago. I find I use it way more often than I would've expected. In 2021! Part of it is that I used it (well, TEST, but the syntax is identical) extensively way way back when, and my fingers still know what to do. Yeah, it's clunky and has all kinds of weird restrictions, but it's sort of the vi of TSO - always there. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
On Fri, 26 Feb 2021 at 02:46, Tom Brennan wrote: > > Is the TSO TESTAUTH command still around? I have to admit I can't > remember ever trying it. It's still there, and works much the way it did 40 years ago. I find I use it way more often than I would've expected. In 2021! Part of it is that I used it (well, TEST, but the syntax is identical) extensively way way back when, and my fingers still know what to do. Yeah, it's clunky and has all kinds of weird restrictions, but it's sort of the vi of TSO - always there. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using BSAM with large block interface
Thank you I’m using VB > On Feb 26, 2021, at 4:36 PM, Mike Schwab wrote: > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/len99.htm#len99 > > Undefined-length records when using LBI or for fixed-length blocked: > The method described in the following paragraphs can be used to > calculate the block length. You can use this method with BSAM, BPAM, > or BDAM. (It should not be used when using chained scheduling with > format-U records. In that case, the length of a record cannot be > determined. > > After issuing the CHECK macro for the DECB for the READ request, but > before issuing any subsequent data management macros that specif > > If you are using LBI for BSAM or BPAM, subtract 12 from the address of > the status area. This gives the address of the 4 bytes that contain > the length of the block read. > >> On Fri, Feb 26, 2021 at 3:00 PM Joseph Reichman >> wrote: >> >> Hi >> >> If I code a DCBE and specify a large block interface >> Larger than that allowed on the DCB >> >> Would anyone know after the I/o is complete >> His many bytes are actually read >> >> Thanks >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SHARE 2021 Virtual is Next Week - Be There or Be Square!
Be There or Be Square! https://www.linkedin.com/feed/update/urn:li:activity:6771082070547591168/ -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using BSAM with large block interface
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/len99.htm#len99 Undefined-length records when using LBI or for fixed-length blocked: The method described in the following paragraphs can be used to calculate the block length. You can use this method with BSAM, BPAM, or BDAM. (It should not be used when using chained scheduling with format-U records. In that case, the length of a record cannot be determined. After issuing the CHECK macro for the DECB for the READ request, but before issuing any subsequent data management macros that specif If you are using LBI for BSAM or BPAM, subtract 12 from the address of the status area. This gives the address of the 4 bytes that contain the length of the block read. On Fri, Feb 26, 2021 at 3:00 PM Joseph Reichman wrote: > > Hi > > If I code a DCBE and specify a large block interface > Larger than that allowed on the DCB > > Would anyone know after the I/o is complete > His many bytes are actually read > > Thanks > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Using BSAM with large block interface
Hi If I code a DCBE and specify a large block interface Larger than that allowed on the DCB Would anyone know after the I/o is complete His many bytes are actually read Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Colours on screen (mainframe history question)
Gentlemen, Thank you all for the answers. Some background of the question: Sometimes I have to do with IT folks hostile to mainframe. Isn't it usual? Maybe, but it's boring and sometimes annoying. Especially when you have to explain mainframe "black screen" is colorful and it was colorful long before Windows get colorful. Now I have precise answer for that. And there is a source in wiki. ;-) Stupid? I had to explain there are relational database on z/OS. And prove it. There are a lot of stupid and false myths. One of myths I had to explain was an article saying z/OS APF can be updated by anyone who wants to put scripts there. (yes, scripts). Nevermind, thank you. -- Radoslaw Skorupka (looking for new job) Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
One of the best troubleshooters I know was a big photograph of a dog. This dog had an 80% success rate! The photo belonged to the expert, and you could only ask the expert once you had asked the dog. Of course everyone would roll their eyes, tut and explain their problem to the dog. In doing so people solved their own problems. As I said - it had a high success rate! On Fri, 26 Feb 2021 at 18:03, Ramsey Hallman wrote: > I agree with Syrmour's method. When I am stumped, I'll start an email to > my boss (the best assembler coder I know) asking what I've done wrong. > While putting as much information into the email as possible, so he doesn't > think I'm taking the easy way out, 99 times out of 100 I'll find my issue. > Usually, it's something fairly minor that I've simply overlooked as > "obviously correct" or "obviously not the area of the problem." When I > point this out to my boss, he usually says "desk check" your code. But I > live by the motto that was posted here some time in the past - Months of > coding and debugging beats hours of desk checking any day. (or something > very close to that LOL). > Ramsey > > > > On Fri, Feb 26, 2021 at 11:09 AM Seymour J Metz wrote: > > > With regard to Tom's second method, often *I* spot the error when I'm > > asking for help and explaining the code. Somehow it seems to sometimes > cure > > a mental blind spot. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > > of Charles Mills [charl...@mcn.org] > > Sent: Friday, February 26, 2021 11:20 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Assembler - Authorized program debug > > > > I really second Tom's latter method. Try walking through the code with > > someone else -- explain to them how it works instruction by instruction. > I > > have good luck with that method using my wife as a sounding board -- even > > though she doesn't know L from ST. > > > > I think many respondents are answering the wrong question. The OP's > > question is not "how do I debug or prevent an S047?" He understands the > > S047. His question is "how do I debug this code without triggering an > > unrelated but well-deserved S047?" > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Tom Brennan > > Sent: Thursday, February 25, 2021 11:46 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Assembler - Authorized program debug > > > > Is the TSO TESTAUTH command still around? I have to admit I can't > > remember ever trying it. My debugging method of such code typically > > consisted of multiple temporary WTO's to let me know where the program > > was at before it failed, and also display fields or registers I was > > interested in. Usually within a few iterations of that method, I'd > > figure out my problem. > > > > Another method: After looking at your code for hours and hours, have > > someone else peek over your shoulder and invariably they will see the > > problem in seconds. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
Sorry for the "fat fingers", Seymour. On Fri, Feb 26, 2021 at 12:02 PM Ramsey Hallman wrote: > I agree with Syrmour's method. When I am stumped, I'll start an email to > my boss (the best assembler coder I know) asking what I've done wrong. > While putting as much information into the email as possible, so he doesn't > think I'm taking the easy way out, 99 times out of 100 I'll find my issue. > Usually, it's something fairly minor that I've simply overlooked as > "obviously correct" or "obviously not the area of the problem." When I > point this out to my boss, he usually says "desk check" your code. But I > live by the motto that was posted here some time in the past - Months of > coding and debugging beats hours of desk checking any day. (or something > very close to that LOL). > Ramsey > > > > On Fri, Feb 26, 2021 at 11:09 AM Seymour J Metz wrote: > >> With regard to Tom's second method, often *I* spot the error when I'm >> asking for help and explaining the code. Somehow it seems to sometimes cure >> a mental blind spot. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf >> of Charles Mills [charl...@mcn.org] >> Sent: Friday, February 26, 2021 11:20 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Assembler - Authorized program debug >> >> I really second Tom's latter method. Try walking through the code with >> someone else -- explain to them how it works instruction by instruction. I >> have good luck with that method using my wife as a sounding board -- even >> though she doesn't know L from ST. >> >> I think many respondents are answering the wrong question. The OP's >> question is not "how do I debug or prevent an S047?" He understands the >> S047. His question is "how do I debug this code without triggering an >> unrelated but well-deserved S047?" >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Tom Brennan >> Sent: Thursday, February 25, 2021 11:46 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Assembler - Authorized program debug >> >> Is the TSO TESTAUTH command still around? I have to admit I can't >> remember ever trying it. My debugging method of such code typically >> consisted of multiple temporary WTO's to let me know where the program >> was at before it failed, and also display fields or registers I was >> interested in. Usually within a few iterations of that method, I'd >> figure out my problem. >> >> Another method: After looking at your code for hours and hours, have >> someone else peek over your shoulder and invariably they will see the >> problem in seconds. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
I agree with Syrmour's method. When I am stumped, I'll start an email to my boss (the best assembler coder I know) asking what I've done wrong. While putting as much information into the email as possible, so he doesn't think I'm taking the easy way out, 99 times out of 100 I'll find my issue. Usually, it's something fairly minor that I've simply overlooked as "obviously correct" or "obviously not the area of the problem." When I point this out to my boss, he usually says "desk check" your code. But I live by the motto that was posted here some time in the past - Months of coding and debugging beats hours of desk checking any day. (or something very close to that LOL). Ramsey On Fri, Feb 26, 2021 at 11:09 AM Seymour J Metz wrote: > With regard to Tom's second method, often *I* spot the error when I'm > asking for help and explaining the code. Somehow it seems to sometimes cure > a mental blind spot. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Charles Mills [charl...@mcn.org] > Sent: Friday, February 26, 2021 11:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Assembler - Authorized program debug > > I really second Tom's latter method. Try walking through the code with > someone else -- explain to them how it works instruction by instruction. I > have good luck with that method using my wife as a sounding board -- even > though she doesn't know L from ST. > > I think many respondents are answering the wrong question. The OP's > question is not "how do I debug or prevent an S047?" He understands the > S047. His question is "how do I debug this code without triggering an > unrelated but well-deserved S047?" > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tom Brennan > Sent: Thursday, February 25, 2021 11:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Assembler - Authorized program debug > > Is the TSO TESTAUTH command still around? I have to admit I can't > remember ever trying it. My debugging method of such code typically > consisted of multiple temporary WTO's to let me know where the program > was at before it failed, and also display fields or registers I was > interested in. Usually within a few iterations of that method, I'd > figure out my problem. > > Another method: After looking at your code for hours and hours, have > someone else peek over your shoulder and invariably they will see the > problem in seconds. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Colours on screen (mainframe history question)
Green snow storms. :-) Cheers, Martin Martin Packer WW z/OS Performance, Capacity and Architecture, IBM Technology Sales +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://mainframeperformancetopics.com Mainframe, Performance, Topics Podcast Series (With Marna Walle): https://anchor.fm/marna-walle Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Jim Elliott To: IBM-MAIN@LISTSERV.UA.EDU Date: 26/02/2021 15:56 Subject:[EXTERNAL] Re: Colours on screen (mainframe history question) Sent by:IBM Mainframe Discussion List I was working in the IBM Toronto Lab prior to the 3279 announcement and was a tester for the product (developed at IBM Hursley). Somewhere I have a photo of myself sitting at my 3279 when I got an award. I still have a copy of a pre-announce version of a paper on developing colour applications (the doc is printed in colour, unusual for the time). Remember the lightning bolts as the early 3279 models displayed graphics? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
With regard to Tom's second method, often *I* spot the error when I'm asking for help and explaining the code. Somehow it seems to sometimes cure a mental blind spot. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Friday, February 26, 2021 11:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler - Authorized program debug I really second Tom's latter method. Try walking through the code with someone else -- explain to them how it works instruction by instruction. I have good luck with that method using my wife as a sounding board -- even though she doesn't know L from ST. I think many respondents are answering the wrong question. The OP's question is not "how do I debug or prevent an S047?" He understands the S047. His question is "how do I debug this code without triggering an unrelated but well-deserved S047?" Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Thursday, February 25, 2021 11:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler - Authorized program debug Is the TSO TESTAUTH command still around? I have to admit I can't remember ever trying it. My debugging method of such code typically consisted of multiple temporary WTO's to let me know where the program was at before it failed, and also display fields or registers I was interested in. Usually within a few iterations of that method, I'd figure out my problem. Another method: After looking at your code for hours and hours, have someone else peek over your shoulder and invariably they will see the problem in seconds. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
I doubt that TESTAUTH will ever go away, but I suggest that you look at the HLA Toolkit or a 3rd party product, since TESTAUTH is pretty barebones. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Brennan [t...@tombrennansoftware.com] Sent: Friday, February 26, 2021 2:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler - Authorized program debug Is the TSO TESTAUTH command still around? I have to admit I can't remember ever trying it. My debugging method of such code typically consisted of multiple temporary WTO's to let me know where the program was at before it failed, and also display fields or registers I was interested in. Usually within a few iterations of that method, I'd figure out my problem. Another method: After looking at your code for hours and hours, have someone else peek over your shoulder and invariably they will see the problem in seconds. On 2/25/2021 9:57 PM, Ravi Gaur wrote: > **Positing in Assembler group as well** - However given the activity thought > to put it in IBM-Main as well. > > Writing and debugging an assembler code which has MODESET instruction to > change key and while debugging it via IDF or Debug tool both abend with > S047(APF) issue. Anyone know a way to debug facility for code without using > IDF/Debug tool? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
I really second Tom's latter method. Try walking through the code with someone else -- explain to them how it works instruction by instruction. I have good luck with that method using my wife as a sounding board -- even though she doesn't know L from ST. I think many respondents are answering the wrong question. The OP's question is not "how do I debug or prevent an S047?" He understands the S047. His question is "how do I debug this code without triggering an unrelated but well-deserved S047?" Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Thursday, February 25, 2021 11:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler - Authorized program debug Is the TSO TESTAUTH command still around? I have to admit I can't remember ever trying it. My debugging method of such code typically consisted of multiple temporary WTO's to let me know where the program was at before it failed, and also display fields or registers I was interested in. Usually within a few iterations of that method, I'd figure out my problem. Another method: After looking at your code for hours and hours, have someone else peek over your shoulder and invariably they will see the problem in seconds. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Colours on screen (mainframe history question)
I was working in the IBM Toronto Lab prior to the 3279 announcement and was a tester for the product (developed at IBM Hursley). Somewhere I have a photo of myself sitting at my 3279 when I got an award. I still have a copy of a pre-announce version of a paper on developing colour applications (the doc is printed in colour, unusual for the time). Remember the lightning bolts as the early 3279 models displayed graphics? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CUCI V1R5 now available at http://www.cbttape.org/ftp/updates/CBT967.zip
FYI, I'm pleased to announce the latest V1R5 release of the CBT Usermod Collection for ISPF (CUCI), available at http://www.cbttape.org/ftp/updates/CBT967.zip. V1R5 now satisfies 33 RFE's, after adding the following: RFE 148758 - ISPF Edit highlighting for Kotlin RFE 148595 - ISPF Edit highlighting for XMLASCII RFE 148594 - ISPF Edit highlighting for SAS RFE 148593 - ISPF Edit highlighting for Perl CUCI has now added 17 new languages for highlighting: CARLa FLOWASM FORTRAN Go JAVA JavaScript JSON Kotlin Perl PHP PYTHON RUBY SAS SHELL SQL TypeScript XMLASCII Other enhancements include: USRCCONF dialog to set ISPF defaults for settings not in ISPCCONF: - PF Keys and PF Key Labels - Calendar Options - MEMLIST, DSLIST, and UDLIST SRCHFOR Options - UDLIST Directory List and Mount Table Options - UDLIST Directory List Column Arrangement - UDLIST Mount Table by File System Column Arrangement - UDLIST Mount Table by Mount Point Column Arrangement - Miscellaneous ISPF Options ISPF OPT3.4 block deletes do not stop on VSAM datasets Reset UID=0 to user's default UID when exiting 3.17 and ISHELL COMPARE, COPY, CREATE, REPLACE commands in 3.17 will prepend path, so you just specify the filename ...and much more! Please download CUCI and try it out. Please also let me know if you have any questions or concerns. -- Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
Hi David, Yes believe that would help and uploading that on CBT will definitely be useful to many others like me. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
Hi Ravi, Barbara, If you want to trace the execution of the program (instead of just one snapshot (as Barbara is suggesting)), you might want to consider setting up a SLIP Trap with TRACE, capturing your data with GTF and using IPCS (via ISPF or Batch) to print the Trace. I am currently working on a situation like this. (I am also developing a Rexx Exec to make the output of the printed Trace more easily readable.) If you'd like more information on this, please respond. Sam: Please let me know if you'd like my finished product for the CBT Tape. Regards, David On 2021-02-26 01:02, Barbara Nitz wrote: On Thu, 25 Feb 2021 23:57:08 -0600, Ravi Gaur wrote: Writing and debugging an assembler code which has MODESET instruction to change key and while debugging it via IDF or Debug tool both abend with S047(APF) issue. Anyone know a way to debug facility for code without using IDF/Debug tool? Set a slip trap on s=047 and use IPCS to read the resulting sdump. Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler - Authorized program debug
First check your steplib - and all the libraries in steplib are APF authorised! Secondly check binder setting AC Colin On Fri, 26 Feb 2021 at 05:57, Ravi Gaur wrote: > **Positing in Assembler group as well** - However given the activity > thought to put it in IBM-Main as well. > > Writing and debugging an assembler code which has MODESET instruction to > change key and while debugging it via IDF or Debug tool both abend with > S047(APF) issue. Anyone know a way to debug facility for code without using > IDF/Debug tool? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
