Re: Cobol dynamic file allocation using SETENV and C run time environment
SCEELKED contains SETENV and PUTENV. 'setenv' may be in SCEELKED, but that does not help the dynamic call case, where the call would be resolved at runtime, not link time. You cannot call lower case names dynamically from COBOL at this time. The dynamic call routine 'normalizes' all names, including setting to upper case. We need to change this at some point, but for now, no dynamic calls to lower-case named subroutines. Can you change your call to a static call? I found CEE.SCEELKED in SYS1.PARMLIB(LPALST00) and the library does contain a SETENV member. So I don't know why the COBOL program is saying that it cannot find the module. You do not CALL objects in SCEELKED, you LINK objects in SCEELKED. The objects in SCEELKED are just 'stubs' that get you to the actual programs in SCEERUN. I tested calling setenv dynamically in a testcase that was working with static calls but failed when I changed the static calls to dynamic (compiled with the DYNAM compiler option) I got S806, subroutine 'setenv' not found. Now I look again, and it was not looking for 'SETENV', it was looking for 'setenv'! Then I look in SCEERUN and SCEERUN2 and cannot find setenv or SETENV. I think it is because they have funny C names that get mangled to fit the real world. Sorry for not remembering the correct solution, which was provided by LE a few years ago: CEEENV! CEEENV can be called statically or dynamically, and can be found in SCEERUN. It provides similar functionality as 'setenv'. Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Data offload to DVDs or external drives
David O'Brien posts: The following has been posed by one of our mainframe users. QUESTION: What options (if any) are available for migrating these old study files and contents of accounts to storage media such as DVDs and external hard drives that could be securely held (off-line) by the agencies? Looking at the user id provided I find that most of these files are VSAM. Is there any way to use VSAM in a non-mainframe environment? Is there a way to write directly to a dvd from a mainframe? There have been a lot of replies already, but I think there's also a lot of guessing going on. Let's not guess too much. The most reasonable question to ask at this point is What business problem(s) are you trying to solve? Without that context, it's difficult to answer these questions. To answer the questions to the degree possible for now: 1. There are myriad options for copying data. Mainframe-accessible data are also ones and zeros. Several copy methods have been mentioned, and I could probably come up with a dozen more. (IND$FILE? Kermit? :-)) What would you prefer? 2. Maybe there is a way to use VSAM (data) in a non-mainframe environment. The data are ones and zeros, regardless of platform. Interpreting the data is another question. What programs interpret and process the data today? How were those programs created, and how are they maintained? Is NIH's requirement to preserve the ability to run those programs upon demand for some period of time and to preserve the associated data for the same period of time? And to do that in a way that reliably reproduces original study results (and potential new results based on older data), with the integrity associated with careful medical research? For how long? Or are there some other (or additional) requirements? Is that an ongoing requirement for current and future studies, to have a computing infrastructure that supports long-term retention of data *and the ability to interpret those data*? That's exactly what mainframes are designed to do. There are programs written in the mid-1960s (and perhaps even earlier) that are still running today, still processing and interpreting their data. Medical research goes back at least that far, including groundbreaking studies on smoking and cancer (for example). This is something NIH really ought to be thinking about, carefully, and at senior levels. The central design premise of mainframes is avoid breaking programs if at all possible. In contrast, our PCs (and Macs) break programs practically every year that passes. Archivists are warning that society is rushing headlong into creating a big digital hole in the historical record, because we simply won't be able to process and interpret older data (even if we have it) even a few years from now. Mainframes are a very notable exception, precisely because many businesses have the same requirements. Many insurance companies, for example, need to retain policies and the processing rules associated with those policies for 100 years or more (the lifetime of a life insurance policyholder and his/her heirs). Mainframes do that -- and support running brand new programs written 5 minutes ago. 3. Yes, actually. (There's at least one vendor that sells hardware to do that.) To what purpose? Many/most mainframes have tape available, often HSM-managed, which works beautifully for archiving programs and data -- and for managing the ability to carry those data forward for decades through technology changes, if that's the retention policy. (And I could see why that might be the retention policy for certain NIH programs and data. Cancer studies need to be long-running, for example. Same with research into chemicals that mimic hormones, which are very subtle and gradual but extremely serious, to pick another example.) If the business problem is to save money, bear in mind that programs that don't run consume zero CPU and data stored on tape consumes (a part of) a tape. That's it. Mainframes are exceptionally talented at (centralized cloud) archiving, because that's what businesses (and governments) need to do quite often, and those are the systems they buy to do it. I'm hard pressed to think of another option that could be less expensive in the real world. If somebody is charging someone else within the same federal government a price that bears no relation to that reality, then that's the business problem to solve -- certainly for the sake of this taxpayer and millions of others. Timothy Sipples Resident Enterprise Architect (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DS8800 ESQA bytes (IBM update)
1. If you specify LOCANY=YES then all of the UCBs will be in ESQA. The HCD Planning manual is wrong. The expectation is there will be 216 bytes of ESQA for each UCB. We are starting the process to get this manual updated. 2. They recommend you use the HCD panels vs the bottom line command because this will use the user's address space to do the activate rather than the Master address space and will provide more virtual storage to process all of the devices -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: maxsystem in a sysplex - belated heads-up
To clarify some technical issues that have been discussed in this thread: On the second and subsequent systems to join the sysplex, XCF signaling has a chicken-and-egg problem when it attempts to determine what signaling connectivity exists with other systems. It may be that the only signaling paths available are via XCF signaling structures, but it must perform this evaluation at a point in IPL *before* the CFRM couple data set has been brought into use. It therefore does not use the CFRM CDS in the normal manner. It is permitted to perform a limited subset of the operations normally available, viz., unserialized reads of individual subrecords of the CFRM active policy, to determine what structures exist. Unserialized reads are permitted specifically because they do not depend on the MAXSYSTEM parameter with which the CDS was formatted, whereas serialized operations do depend on MAXSYSTEM. (The number of systems for which the CDS was formatted determines the number of lock blocks that are used to ensure that operations initiated by one sy! stem do not collide with operations initiated by another.) XCF is not lying to you when it establishes connectivity via signaling structures but later rejects the CFRM CDS because it is formatted for too few systems. XCF does not and never will wait state simply because it is unable to use a function CDS (i.e., a CDS of type other than sysplex). In the specific case of the CFRM CDS, XCF cannot determine that the installation is trying to IPL in GRS star mode, nor does XCF even understand that the CFRM CDS is required for star mode. For other CDS types, it is perfectly possible for a system to continue running if it doesn't have access to that CDS. I don't think it would be popular if XCF wait stated because the CFRM CDS was formatted for foo few systems when the plex was running in ring mode, or if it wait stated because the n'th system into the plex couldn't use the ARM (or SFM or Logger or WLM or BPX) CDS. Instead, we should - and do - permit the system to IPL into the plex, report that it can't use the function, and allow the installation to take corrective action by making a larger CDS available. The change to retain information about inactive systems in the sysplex CDS was implemented in support of a business resilience function that provided infrastructure for automated management of sysplex resources. That structure required the ability to retain sysplex-related information even across sysplex-wide IPLs. Because of the retention requirement, I doubt that we would implement a function to automatically purge inactive systems after some period. We would have the same problem we always have when trying to choose a threshold - whatever we chose would be too short for some installations, too long for others, and not correct for anyone. We'd have to introduce yet another parameter for customers to manage, to control the retention period. Bill Neiman Parallel Sysplex development IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Segmenting an output spool file in z/OS - 2nd attempt
The original version was sent from my Outlook mail client in HTML format. I have since changed my default email format to Rich Text, because Outlook has an option to convert Rich Text messages as plain text when they're sent to the internet Leslie Turriff -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Joel C. Ewing Sent: Thursday, October 20, 2011 17:48 To: IBM-MAIN@bama.ua.edu Subject: Re: Segmenting an output spool file in z/OS - 2nd attempt Leslie, Off topic, but did you do anything different on 2nd posting to get it to work? Like something we could advise for others with similar base64 posting issues? I received some additional headers from ibm-main with your 2nd posting attempt, most notably a X-MIME-Autoconverted: from base64 to 8bit by bama.ua.edu id p9KEf61i001292 which implies Email was still received by bama in base64 format, but for some reason it was able to convert the 2nd post to 8bit and handle it reasonably but failed to do so for the 1st. From the Received headers, it looks like the 2nd posting was received by a different ua.edu mail server than the first post (mailapp-2.ua.edu versus mailapp-1.ua.edu), so perhaps the difference is an issue at ua.edu. Maybe they're experimenting with a circumvention/resolution of the original problem and you just hit a fixed path on 2nd try. (The routing of Email though mo.gov servers was different as well, but base64 encoding apparently got to bama in both cases) JC Ewing On 10/20/2011 09:41 AM, Turriff, Leslie wrote: Hi, I know that in z/VM and z/VSE I can break a large output spool file into several segments. I've Googled, and looked through the z/OS JCL Reference and User Guide and the JES2 Introduction and Commands manuals, but I can't find an equivalent mechanism for z/OS. Perhaps a different term is used in z/OS, and I'm looking for the wrong thing? Leslie Turriff State of Missouri Information Technology Services Division -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DS8800 ESQA bytes (IBM update)
On Fri, 21 Oct 2011 06:15:36 -0500, J Ellis jerry.el...@libertymutual.com wrote: 1. If you specify LOCANY=YES then all of the UCBs will be in ESQA. The HCD Planning manual is wrong. The expectation is there will be 216 bytes of ESQA for each UCB. We are starting the process to get this manual updated. 2. They recommend you use the HCD panels vs the bottom line command because this will use the user's address space to do the activate rather than the Master address space and will provide more virtual storage to process all of the devices In your last post (which you didn't reference) you wrote this: According to IBM, with LOC=ANY, for DASD, it's 274 bytes in SQA, 136 bytes in ESQA. and, we will knock a meg out of our private area if we add the 10K device. That didn't make any sense, but you wrote according to IBM and that seemed to indicate you opened a PMR or had some sort of definitive information from someone who knew the exact numbers. So now you've probably confused people and for the sake of the archives, maybe should should clarify the numbers. Also, using HCD panels vs the bottom line command? I assume bottom line command refers to issuing the ACTIVATE command to a console via SDSF, some other method, or a real console as opposed to using the panels. Your initial concerned seemed to be about private area after the fact and at NIP vs. dynamic activation. Those are also two different issues related to this discussion. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Segmenting an output spool file in z/OS - 2nd attempt
I intended to say: The original version was sent from my Outlook mail client in HTML format. I have since changed my default email format to Rich Text, because Outlook has an option to convert Rich Text messages as plain text when they're sent to the internet. Leslie Turriff -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Turriff, Leslie Sent: Friday, October 21, 2011 08:37 To: IBM-MAIN@bama.ua.edu Subject: Re: Segmenting an output spool file in z/OS - 2nd attempt The original version was sent from my Outlook mail client in HTML format. I have since changed my default email format to Rich Text, because Outlook has an option to convert Rich Text messages as plain text when they're sent to the internet Leslie Turriff -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Joel C. Ewing Sent: Thursday, October 20, 2011 17:48 To: IBM-MAIN@bama.ua.edu Subject: Re: Segmenting an output spool file in z/OS - 2nd attempt Leslie, Off topic, but did you do anything different on 2nd posting to get it to work? Like something we could advise for others with similar base64 posting issues? I received some additional headers from ibm-main with your 2nd posting attempt, most notably a X-MIME-Autoconverted: from base64 to 8bit by bama.ua.edu id p9KEf61i001292 which implies Email was still received by bama in base64 format, but for some reason it was able to convert the 2nd post to 8bit and handle it reasonably but failed to do so for the 1st. From the Received headers, it looks like the 2nd posting was received by a different ua.edu mail server than the first post (mailapp-2.ua.edu versus mailapp-1.ua.edu), so perhaps the difference is an issue at ua.edu. Maybe they're experimenting with a circumvention/resolution of the original problem and you just hit a fixed path on 2nd try. (The routing of Email though mo.gov servers was different as well, but base64 encoding apparently got to bama in both cases) JC Ewing On 10/20/2011 09:41 AM, Turriff, Leslie wrote: Hi, I know that in z/VM and z/VSE I can break a large output spool file into several segments. I've Googled, and looked through the z/OS JCL Reference and User Guide and the JES2 Introduction and Commands manuals, but I can't find an equivalent mechanism for z/OS. Perhaps a different term is used in z/OS, and I'm looking for the wrong thing? Leslie Turriff State of Missouri Information Technology Services Division -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: maxsystem in a sysplex - belated heads-up
Hi, I would also point out that from an XCF design perspective, it is perfectly acceptable to have a function CDS be accessible from a subset of the systems, In practice, the requirement imposed by the exploiters is that the function CDS be accessible from all systems that require the function. For many exploiters, that is tantamount to requiring that the function CDS be accessible from every system in the sysplex. But it is not a requirement that XCF imposes. The XCF signalling service does NOT lie about establishing signalling connectivity with other systems. If we issue a message saying we established it, then we did. It might change a nanosecond later, but as of the moment that we decided to issue the message, it was truth. Bill Neiman is correct about the chicken and egg situation. To be a little more precise, the IPLing system takes a look at the signalling structures that have been defined for its use. We then peek inside the CFRM CDS to see if those structures have been physically allocated. For those structures that exist, we then do a limited form of connect to the structure that permits us to go read XCF control data from the respective signalling structures. We use that information to determine what other systems are using the structure for signalling. Based on that data, we then forecast what signalling paths would be established if the IPL were to continue. If the predicted paths (along with any ones that have actually been established -- ie CTC paths) are not sufficient to establish connectivity, XCF complains about insufficient signalling paths and prompts the operator to resolve the problem. If the predicted paths appear to be sufficient for establishing connectivity, we allow the system to proceed to become active in the sysplex. As soon as the system becomes active in the sysplex, it can now use the CFRM policy and related CF structures for real. So the first thing XCF does is connect to the signal structures for real and attempt to establish full signalling connectivity. If we do establish connectivity with every other system in the sysplex, we issue truthful messages to say so and the IPL proceeds. If we cannot establish signalling connectivity with every other system in the sysplex, the IPL does NOT proceed. And we engage the operator to express our displeasure and plead for resolution. Only on the rarest of occasions have I ever seen situations where the predicted paths fail to become real paths and connectivity is not established. I can certainly envision cases where it wouldn't work. The simplest one would be to have the active systems stop using the structure (s) for signalling between the time that the IPLing system looks to see who was using the structures and the time it gets around to actually trying to establish those paths for real. In short, an IPLing system will not make it into the sysplex unless it appears to have a reasonable chance of establishing signalling connectivity, and the IPL will not proceed unless it actually can. The interior workings are likely a mystery to many. I suspect there is much that can be misinterpreted. But we do not lie. If a message was in fact issued to indicate that connectivity was established when it in fact had not, please open a defect and we will fix it. We do not intentionally issue false and misleading messages. Mark A. Brooks z/OS Sysplex design and development 845-435-5149 T/L 8-295-5149 Poughkeepsie, NY mabr...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Where can I find more info about Jes3 and Basic Hyperswap?
*** Cross posted to IBM-MAIN JES3-L *** Hi, *Question fully contained in the subject.* ** ** It's been a loong time that I did JES3 ... ** Where can I find more info about Jes3 and Basic Hyperswap? BASIC Hyperswap, NOT GDPS Hyperswap. It is supported while I found these 2 things: 1° SG24-7563-00 IBM TotalStorage Productivity Center for Replication for Series z (draft 20 may 2008) (still draft ???) http://www.redbooks.ibm.com/redpieces/abstracts/sg247563.html page 233-234 6.4.3-JES3 Considerations 2° OA34126: HYPERSWAP NOT READY AFTER JES3 PROBLEMS CONNECTING TO GLOBAL CLEARED(2010-12-08) http://www-01.ibm.com/support/docview.wss?uid=isg1OA34126 Jan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Web page , link to all (most) z/OS messages
LookAt! will find CICS DB2 messages ie. -904, DSNT..., DFH..., etc. I've found that you'll be presented with a secondary web page that requires you to select the version. -- 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 -Original Message- From: Miklos Szigetvari [mailto:mik...szi...@isicom] Sent: October 10, 2011 05:25 Subject: Web page , link to all (most) z/OS messages Searching something like Lookat, which would contain all (or most) of the z/OS messages. In the Lookat there is no DB2, CICS, MQ etc etc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help with Tape Hardware Issue TS3500
Lizette: we also encountered a 'lost' tape with our 3494 ATL. In the linear frames/hallway where the gripper runs, there is a supporting strut/bar along the floor that parallels the gripper's drive/tooth track. The bar is wide enough just high enough above the floor panels to hide a 3590 cartridge. The cartridge isn't visible unless you're looking back towards the open door ie. from the drive side of the hallway. (Our ops guy spotted it by accident when he was leaning inside the frame to look closely at the drive status panel and caught a flash of colour from the external tape label.) Don't know if this translates to your TS3500 but you might cop a feel along the floor panels to see what (other than dust bunnies) you might discover in the nooks crannies. (The same ops guy found two more cartridges elsewhere in the 3494 by touch. We speculate that the gripper lost contact while spinning to the opposite side essentially launching the cartridge across the floor like a Frisbee.) -- 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 -Original Message- From: Linda Mooney [mailto:lin..ls...@com...net] Sent: October 18, 2011 16:20 Subject: Re: Help with Tape Hardware Issue TS3500 [snip] 3494 ATL. [snip] a tape go missing with last status of being in the gripper. Both times, we found the tape on the floor of the ATL, once bumped underneath the edge of one of the drives in the ATL and once one the floor by the robot's 'garage'. - Original Message - From: Lizette Koehler star...@min...com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, October 18, 2011 12:55:17 PM Subject: Help with Tape Hardware Issue TS3500 I had a hardware failure of some kind on Oct 15. Today I am missing the tape that was indicated in the messages. I looked at the ATL through the web interface and it says it is in the gripper(acc1,g1) [snip] The Operators have opened up the ATL and manually scanned for the tape. [snip] The hardware support vendor says they did not remove any tapes [snip] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cobol dynamic file allocation using SETENV and C run time environment
Yes Rick - Scott Ford wrote: Rick: Your saying even if specified, it is overriden by the Linkage Editor and Binder ? Scott J Ford Software Engineer http://www.identityforge.com From: Rick Fochtman rfocht...@ync.net To: IBM-MAIN@bama.ua.edu Sent: Thursday, October 20, 2011 7:59 PM Subject: Re: Cobol dynamic file allocation using SETENV and C run time environment -snip Scott, Interesting side point to me. Does specifying a DCB on sysut1 on the linkedit make a difference on the block size of the lmod? Not the size but the block size? Ed -unsnip Ed, to the best of my knowledge, any such value on the DD statement is ignored. Linkage Editor of Binder will determine what's best for its purposes without our help. AFAIK, the LMOD blksize is determined solely by the SYSLMOD blksize value. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cobol dynamic file allocation using SETENV and C run time environment
Rick, I was looking at our LE compile proc and I think the allocations were carry over by someone. I just never thought about changing them. Funny how that happens. Thanks for the reply, much appreciated Scott J Ford Software Engineer http://www.identityforge.com From: Rick Fochtman rfocht...@ync.net To: IBM-MAIN@bama.ua.edu Sent: Friday, October 21, 2011 5:13 PM Subject: Re: Cobol dynamic file allocation using SETENV and C run time environment Yes Rick - Scott Ford wrote: Rick: Your saying even if specified, it is overriden by the Linkage Editor and Binder ? Scott J Ford Software Engineer http://www.identityforge.com From: Rick Fochtman rfocht...@ync.net To: IBM-MAIN@bama.ua.edu Sent: Thursday, October 20, 2011 7:59 PM Subject: Re: Cobol dynamic file allocation using SETENV and C run time environment -snip Scott, Interesting side point to me. Does specifying a DCB on sysut1 on the linkedit make a difference on the block size of the lmod? Not the size but the block size? Ed -unsnip Ed, to the best of my knowledge, any such value on the DD statement is ignored. Linkage Editor of Binder will determine what's best for its purposes without our help. AFAIK, the LMOD blksize is determined solely by the SYSLMOD blksize value. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
