OMVS command history
Hi All, Something's puzzled me for some time and I wonder if it is a quirk at this site. When I go into OMVS and enter a command, I can then press F12 to recall it. Repeatedly pressing F12 brings back older commands. That's great but when I go out and come back in, pressing F12 does nothing until I've entered a command. I notice that there is a file called .sh_history.mysuerid which contains my command history. My question, then, is why is my command history kept if I can't use it? Or is there something set up incorrectly here? Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: migrating compiler versions
Hi Frank, We are in the process of upgrading from COBOL 4.2 to 5.1 and, let me tell you, it's been a nightmare. First off, before even considering ordering 5.2, convert all your load libraries to PDSE - as someone else stated, you have no option. This in itself leads to confusion and mis-information. Questions will arise, e.g. Is it possible to copy from PDSE to PDS? The answer is depends if you compile/link a module using COBOL 4 to a PDSE, it is possible to copy it to a PDS. However, a COBOL 5 modules are linked (bound, really) as program objects and cannot be copied to PDS. When copying load modules (whatever format) using IEBCOPY, behind the scenes it calls the binder to ensure the correct module format. I wrote a REXX exec to take a list of library names, rename the library to have .PDS on the end, allocated a new PDSE library and called IEBCOPY, obviously checking at each stage and making the process restartable. And, unusually, we started with the production libraries and worked our way back through the food chain. Update COBOL 4 to issue MIGR messages, which your developers will ignore no matter how many times you stress the importance of checking and eliminating them. Be aware that due to IBM's (new) licensing policy, you will only be allowed to use COBOL 4 and COBOL 5 concurrently for one year, and again, no matter how much you stress to developers, they'll try to wait till the last minute. In the first release of COBOL 5, there was no AMODE(24) support. That has now been changed but it has led to several S0C4's as some of the compiler modules have not been fixed. Whereas in previous versions of ECOBOL a minimum and maximum record length did not have to be specified when defining a variable file, v5.1 will return a file status of '04' if any record is less than or greater than the minimum / maximum specified. Working-storage BLW cells have been replaced by WSA (Writeable Static Area) which means a change to the way your developers will find their working storage fields in a dump. If you want any help and advice from one who's been through the process, then feel free to ask. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. From: Frank Swarbrick 002782105f5c-dmarc-requ...@listserv.ua.edu To: IBM-MAIN@LISTSERV.UA.EDU, Date: 01/04/2015 00:06 Subject:migrating compiler versions Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Does anyone have a good list of best practices when migrating to a new version of a compiler? While our shop is 35+ years old, we have rarely actually migrated compilers (or even compiler versions), so we don't have a lot of experience in this area. When migrating from DOS/VS COBOL to VS COBOL II there were almost always source code changes, so all programs were tested before they were migrated, and no program was simply automatically migrated, as it were. I'm sure we had COBOL II for at least ten years before all of our DOS/VS COBOL programs were eliminated. (From what I hear that's actually better than many shops, which STILL have pre-COBOL II programs out there!) Going from VS COBOL II to IBM COBOL for VSE/ESA was a more normal migration. If I remember correctly (and I should because I was pretty much in charge of the migration) we at first only migrated to the new compiler if other changes were being made to a program and a special flag was set to indicate that this program should be compiled with the new compiler instead of the older one. Only after many, many programs were migrated in this fashion (and it probably took us several years to get to this point, though I honestly do not recall) did we finally eliminate the COBOL II compiler altogether. But I believe at no point did we do any kind of mass recompile. We simply used COBOL for VSE/ESA for all programs going forward (old-COBOL had all been converted to COBOL II or COBOL for VSE/ESA already). Then we migrated to z/OS and IBM Enterprise COBOL 4.2. Of course in this situation EVERYTHING was recompiled and regression tested. So now we're pondering how to get the Enterprise COBOL 5.2. The easiest thing, of course, would be to simply change our compile procs to use COBOL 5.2. But being as how COBOL 5.2 has been out for only a month that's probably not a good idea. Probably the best thing to do would be to have developers choose to use COBOL 5.2 by this 'setting a flag' for an individual program indicating that their test compiles should use 5.2, and in turn so should their production compiles. Should we also, at least at first, have them do a regression test of the current 4.2 results comparing against the results of the program compiled with 5.2? And for how long should
Re: migrating compiler versions
http://www-01.ibm.com/support/docview.wss?uid=swg1PM93583 Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. From: Elardus Engelbrecht elardus.engelbre...@sita.co.za To: IBM-MAIN@LISTSERV.UA.EDU, Date: 01/04/2015 11:24 Subject:Re: migrating compiler versions Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Ken MacKenzie wrote: We are in the process of upgrading from COBOL 4.2 to 5.1 and, let me tell you, it's been a nightmare. It will be a nightmare. One question to the OP: Are your COBOL programs calling to or are called from other programs compiled in languages like C++, Assembler, PL/I, etc? Then there are compatibility issues with calls to / from DB systems as well to their datasets. Are these systems compatibile with your new COBOL? ... and again, no matter how much you stress to developers, they'll try to wait till the last minute. They will. Trust me... :-( And the users of those programs don't want any downtime! Go figure. In the first release of COBOL 5, there was no AMODE(24) support. That has now been changed ... Sorry to bother you, but with what PTFs / APARs? Just curious if you don't mind please. Whereas in previous versions of ECOBOL a minimum and maximum record length did not have to be specified when defining a variable file, v5.1 will return a file status of '04' if any record is less than or greater than the minimum / maximum specified. Good catch! Thanks for telling. Groete / Greetings Elardus Engelbrecht -- 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: Strange LE / link list behaviour
Thanks to all who replied, I'm still mulling over the information provided. For those that asked, or were curious: SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 We've changed the order of link list libraries on the test system (as far as possible) to reflect development system but the problem still doesn't happen there. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. From: Ken MacKenzie ken.macken...@pramerica.ie To: IBM-MAIN@LISTSERV.UA.EDU, Date: 27/02/2015 09:28 Subject:Strange LE / link list behaviour Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi all, We're in the process of upgrading to Enterprise COBOL 5.1 and one of our development groups has decided to re-compile all their COBOL modules even though it is not deemed necessary - that's their prerogative. One of their programs is exhibiting strange behaviour on the development LPAR that I have been unable to replicate on our sandbox system. If they code the LE libraries SCEERUN and SCEERUN2 in their JOBLIB statement, their program runs OK. However, if they allow the LE libraries to come from link list (as they should) their program abends with S0C4 - the address of the offending instruction is way outside of the module reported in the dump - probably a wild branch, I guess. Has anyone encountered anything similar? Why should coding LE libraries in your JOBLIB (the same with STEPLIB, incidentally) cause a module to work when it doesn't work from link list? Any helpful suggestions welcomed. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. -- 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
Strange LE / link list behaviour
Hi all, We're in the process of upgrading to Enterprise COBOL 5.1 and one of our development groups has decided to re-compile all their COBOL modules even though it is not deemed necessary - that's their prerogative. One of their programs is exhibiting strange behaviour on the development LPAR that I have been unable to replicate on our sandbox system. If they code the LE libraries SCEERUN and SCEERUN2 in their JOBLIB statement, their program runs OK. However, if they allow the LE libraries to come from link list (as they should) their program abends with S0C4 - the address of the offending instruction is way outside of the module reported in the dump - probably a wild branch, I guess. Has anyone encountered anything similar? Why should coding LE libraries in your JOBLIB (the same with STEPLIB, incidentally) cause a module to work when it doesn't work from link list? Any helpful suggestions welcomed. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to identify program language from program object
What happened to AMBLIST? Sorry - I meant visually via BROWSE of the load library. Not very scientific but effective. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN@LISTSERV.UA.EDU, Date: 15/02/2015 00:36 Subject:Re: How to identify program language from program object Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU In off6e52a22.284c8f8c-on85257deb.004d3287-80257deb.005b2...@prudential.com, on 02/13/2015 at 04:35 PM, Ken MacKenzie ken.macken...@pramerica.ie said: In the old days, as far as I remember though I can't prove it, you used to be able to look at a load library member, check for a certain string (e.g. C2 mm/dd/yy hh:mm:ss) and establish that the module - or even modules had been compiled as COBOL II. According to z/OS MVS Program Management: User's Guide and Reference, SA22-7643-09, program objects support IDR data. Wit the advent of program objects on PDSEs and Enterprise COBOL we don't appear to have that luxury. What happened to AMBLIST? Any thoughts? If it were me, I'd use the BINDER for PDSE and Unix program objects rather than post-processing AMBLIST LISTIDR output. -- 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 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: How to identify program language from program object
Unfortunately that seems to be for PDS only not PDSE. Looks good though but not much use now that we're entirely PDSE. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. From: Sri h Kolusu skol...@us.ibm.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 13/02/2015 17:31 Subject:Re: How to identify program language from program object Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Ken, You can look at the signature bytes of the load module and determine the compiler version. Check this out http://www3.sympatico.ca/bredam/LoadInfo.html#LINF Kolusu From: Ken MacKenzie ken.macken...@pramerica.ie To: IBM-MAIN@LISTSERV.UA.EDU Date: 02/13/2015 08:35 AM Subject:How to identify program language from program object Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU In the old days, as far as I remember though I can't prove it, you used to be able to look at a load library member, check for a certain string (e.g. C2 mm/dd/yy hh:mm:ss) and establish that the module - or even modules had been compiled as COBOL II. Wit the advent of program objects on PDSEs and Enterprise COBOL we don't appear to have that luxury. Does anyone know of any way to identify the language type of modules. We have File-AID at this site and it can identify the CSECTs within a module but it doesn't seem to be able to tell me what COBOL version was used As we prepare to establish Enterprise COBOL 5.1 as the default, I've been asked by developers if it is possible to give them a list of what programs were compiled with which compiler and given that our load libraries are now almost 100% PDSE it's proving tricky. Any thoughts? Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. -- 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
How to identify program language from program object
In the old days, as far as I remember though I can't prove it, you used to be able to look at a load library member, check for a certain string (e.g. C2 mm/dd/yy hh:mm:ss) and establish that the module - or even modules had been compiled as COBOL II. Wit the advent of program objects on PDSEs and Enterprise COBOL we don't appear to have that luxury. Does anyone know of any way to identify the language type of modules. We have File-AID at this site and it can identify the CSECTs within a module but it doesn't seem to be able to tell me what COBOL version was used As we prepare to establish Enterprise COBOL 5.1 as the default, I've been asked by developers if it is possible to give them a list of what programs were compiled with which compiler and given that our load libraries are now almost 100% PDSE it's proving tricky. Any thoughts? Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Binder DASD SIZE (and DWARF)
Hi, We've installed Enterprise COBOL 5 in z/OS 2.1 and I'm experimenting with the NOTEST(DWARF) COBOL option. When I Bind the program, I see, for example: MODULE SIZE (HEX) 00072C24 DASD SIZE (HEX) 0014A000 The z/OS V2R1.0 MVS Program Management: User's Guide and Reference manual doesn't give any information on DASD SIZE as far as I can see. I discovered the Binder's COMPRESS option c/w COMPAT=CURR but for my troubles, all I get is: IEW2603I 536F COMPRESSION REQUESTED, BUT NO SAVINGS WAS REALIZABLE. REASON 13 The messages manual here: http://www-01.ibm.com/support/knowledgecenter/#!/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieam800/je6204.htm tells me: The compression dictionary in use did not support this particular program object. And I have no idea what that means. Has anyone been down this path? Any ideas? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Changing Service Class
Hi I wonder if anyone can help point me in the right direction. I have a DCB set up with a DCBE parameter. I'm running in 31-bit mode and I copy the DCB below the line. On my OPEN I get the following message: IEC190I ,, INVALID DCBE: STORAGE NOT ADDRESSABLE Looking at the description of IEC190I is not helping me much. I've tried copying the DCBE below the line and using it from there, I've tried keeping it above the line and using it from there, I've tried plugging the address into DCBDCBE before the open but the message will just not go away. Strange thing is that the OPEN appears to work but I'm encountering an abend later on in processing, which may (or may not) be associated. My routine is an exit routine for a vendor product so I have no real information on the abend is associated. Any ideas? Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEC190I message
Sorry, forgot to change the subject. From: Ken MacKenzie ken.macken...@pramerica.ie To: IBM-MAIN@LISTSERV.UA.EDU, Date: 08/01/2015 16:13 Subject:Re: Changing Service Class Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Hi I wonder if anyone can help point me in the right direction. I have a DCB set up with a DCBE parameter. I'm running in 31-bit mode and I copy the DCB below the line. On my OPEN I get the following message: IEC190I ,, INVALID DCBE: STORAGE NOT ADDRESSABLE Looking at the description of IEC190I is not helping me much. I've tried copying the DCBE below the line and using it from there, I've tried keeping it above the line and using it from there, I've tried plugging the address into DCBDCBE before the open but the message will just not go away. Strange thing is that the OPEN appears to work but I'm encountering an abend later on in processing, which may (or may not) be associated. My routine is an exit routine for a vendor product so I have no real information on the abend is associated. Any ideas? Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. -- 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
Output Writer and TCP/IP
Hi All, I've been asked to look at our output writer routines to add the facility to print using TCP/IP instead of (or maybe as well as) Bus Tag (EXCP.) Can anyone with experience in this area direct me to the relevant IBM documentation, etc? Thanks-in-Advance. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Output Writer and TCP/IP
A third-party product is not completely out of the question but since we have the current external writer routines well ensconced in the system with our own specific tailoring, etc. the thinking is that massaging a new product may be as costly and time consuming as amending what we have. The current routines do all the spool reading already so in some ways, the hardest part is already done. The project's in its infancy right now. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 27/03/2013 12:14 Subject:Re: Output Writer and TCP/IP Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU We use MacKinney's JQP. You put the output on the SPOOL like normal, with a DEST=. JQP is a started task which uses the JES API to read the output. It then uses the LPR protocol over IP to send the output to LPR printers, Windows print servers, and a product called RPM (I think) which runs on Windows and transcribes the LPR print output into a Windows file. I don't know much about RPM, but we use it for our report distribution system: Report to Web. JQP works well for us, and is inexpensive. LRS has VPS/TCPIP. An RYO solution by writing your own external writer type routine is likely not the wisest move. You'd need to write your own routines to read the SPOOL, and then communicate to the remote end via a protocol such as LPR over TCPIP. I'm not saying its impossible, just not as simple as writing to a disk file. If you need a freebie, then there is the every unpopular IBM Network Print Server, which is part of Communictions Server (TCPIP/VTAM). I actually got this working once. It stinks like Limburger cheese left in a closed up car in the Texas summer heat, but it did work. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1G310/CCONTENTS On Wed, Mar 27, 2013 at 4:47 AM, Ken MacKenzie ken.macken...@pramerica.iewrote: Hi All, I've been asked to look at our output writer routines to add the facility to print using TCP/IP instead of (or maybe as well as) Bus Tag (EXCP.) Can anyone with experience in this area direct me to the relevant IBM documentation, etc? Thanks-in-Advance. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. -- 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: Output Writer and TCP/IP
Home-built. Written about 100 years ago by someone who's left the company or died or both. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. From: Pommier, Rex R. rex.pomm...@cnasurety.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 27/03/2013 14:21 Subject:Re: Output Writer and TCP/IP Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Ken, What are you using now? Is it a home-built product or is it, for example, IBM's PSF, or something else? Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ken MacKenzie Sent: Wednesday, March 27, 2013 7:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Output Writer and TCP/IP A third-party product is not completely out of the question but since we have the current external writer routines well ensconced in the system with our own specific tailoring, etc. the thinking is that massaging a new product may be as costly and time consuming as amending what we have. The current routines do all the spool reading already so in some ways, the hardest part is already done. The project's in its infancy right now. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. From: John McKown john.archie.mck...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 27/03/2013 12:14 Subject:Re: Output Writer and TCP/IP Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU We use MacKinney's JQP. You put the output on the SPOOL like normal, with a DEST=. JQP is a started task which uses the JES API to read the output. It then uses the LPR protocol over IP to send the output to LPR printers, Windows print servers, and a product called RPM (I think) which runs on Windows and transcribes the LPR print output into a Windows file. I don't know much about RPM, but we use it for our report distribution system: Report to Web. JQP works well for us, and is inexpensive. LRS has VPS/TCPIP. An RYO solution by writing your own external writer type routine is likely not the wisest move. You'd need to write your own routines to read the SPOOL, and then communicate to the remote end via a protocol such as LPR over TCPIP. I'm not saying its impossible, just not as simple as writing to a disk file. If you need a freebie, then there is the every unpopular IBM Network Print Server, which is part of Communictions Server (TCPIP/VTAM). I actually got this working once. It stinks like Limburger cheese left in a closed up car in the Texas summer heat, but it did work. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1G310/CCONTENTS On Wed, Mar 27, 2013 at 4:47 AM, Ken MacKenzie ken.macken...@pramerica.iewrote: Hi All, I've been asked to look at our output writer routines to add the facility to print using TCP/IP instead of (or maybe as well as) Bus Tag (EXCP.) Can anyone with experience in this area direct me to the relevant IBM documentation, etc? Thanks-in-Advance. Ken MacKenzie Pramerica Systems Ireland Limited is a private company limited by shares incorporated and registered in the Republic of Ireland with registered number 319900 and registered office at 6th Floor, South Bank House, Barrow Street, Dublin 4, Ireland. -- 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 The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited and that you will be held responsible for any such unauthorized activity, including liability for any resulting damages. As appropriate, such incident(s) may also be reported to law enforcement. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended
