If the assembler program is not LE compliant and Reentrant and Reuseable there will be a performance issue when the module is called Dynamically.
Regards Otto Schumacher HP Enterprise Services Infrastructure Specialist Ahold Account CICS & Capacity Technical Support P.O. Box 6462 2000 Wade Hampton Blvd. LC1-302 Greenville, South Carolina, 29606 Cell: 864 569--5338 Tel: 864 987-1417 Fax: 864 987-4500 E-mail: [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Barkow, Eileen Sent: Thursday, July 14, 2011 11:05 AM To: [email protected] Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY These are batch programs that they are working on (I hope, since they are invoking MVS IO routines directly). However, this group of programmers are also heavy CICS users - I did not ask if the programs were CICS or not. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Chase, John Sent: Thursday, July 14, 2011 10:39 AM To: [email protected] Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY How would TCB switching occur at all? Are these programs running in CICS? If so, you cannot use the DYNAM compiler option for COBOL. -jc- > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Barkow, Eileen > Sent: Thursday, July 14, 2011 9:30 AM > To: [email protected] > Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY > > The programmer has a question about possible TCB switching: > > Option 2 seems better. DATA(31) should allow most of the callers storage to reside above the line, and > switch to below the line processing only when calling the assembler routine. Would excessive TCB > switching result if the assembler program is invoked repeatedly for file i/o, or does that not come > into play? > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 > Sent: Wednesday, July 13, 2011 4:53 PM > To: [email protected] > Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY > > Option #1 is simpler, that is true. I also forgot to say that the COBOL compiler option DYNAM will > also be required so that if the 24-bit assembler program is called using CALL literal (like CALL > 'MYASMIO'), then it will be loaded at run time instead of linked in statically. I assume from your > original post that this must be your case, otherwise the programmers would not be worrying about > including the 24-bit program as part of the link step. > > However, Option #2 does have the advantage of allowing the WORKING-STORAGE of the COBOL programs to > grow much larger in 31-bit storage without worrying about using up all available 24-bit storage. If > growth of internal tables or data in the COBOL programs over time is a possible future maintenance > headache for using DATA(24), it might be better (though more work) to bite the bullet and take option > #2 now instead of later. > > OTOH getting that 24-bit assembler I/O program correctly converted to 31-bit is the better long-term > option over all, and DATA(24) plus DYNAM gives you time to do that as a priority. When that is done > you can switch the COBOL compiles to DATA(31) and you're done. > > Good luck, and feel free to ask more questions if you need to. > > HTH > > Peter > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] On > > Behalf Of Barkow, Eileen > > Sent: Wednesday, July 13, 2011 4:06 PM > > To: [email protected] > > Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY > > > > Thank you Peter. > > I missed your post yesterday morning as well as some others. > > I am beginning to think that there was delay in the email yesterday > > morning and the msgs were delivered later in the > > Day so I did not notice the earlier ones. > > > > Option #1 sounds simpler than 2 since it does not require any code > > changes. > -- > > 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 > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- 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
