Re: Sending files to JES
I found the most simple one we've got. Much easier for you to unravel. Some notes - PIPEs gives a INMR123 REXX stage to block pipe records into NETDATA format . We modified this a little, and named that NETDATA+ REXX. - The sample is SMFMVS EXEC. It reads a VM:OPER logfile to extract all LOGON/LOGOFF records and send those to MVS in an SMF-like format. The reason: initially we were asked to send RACFs SMF log to MVS where they would extract LOGON/LOGOFF events to see who was logged on at a system in which time period. As RACF didn't collect LOGOFFs in its SMF file, we scanned the VM operator log and mimicked a bit an SMF file. - At line 201 we store some PIPE stages in a REXX variable: in testmode, the stages are simple: create a CMS file, otherwise the stages create MVS JCL and call NETDATA+ to format the SMF-like records we created from the operator log. - At line 266 we read the operator log, and at line 288 the pipe stages created in the previous step are inserted in the pipeline. - At line 370 the data punched by the pipe are sent to MVS via RSCS. 2011/3/8 Shumate, Scott scshum...@bbandt.com That would be great. Can I take a look at it? Thanks Scott -- *From:* The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] *On Behalf Of *Kris Buelens *Sent:* Tuesday, March 08, 2011 3:47 PM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: Sending files to JES On our VM systems, we had some processes that sent a CMS file embedded in an MVS job. The MVS job started TSO in batch to receive the file. At last that single job could carry multiple CMS files. As a result, the REXX code became less than easy to read for beginners. I can dig that up, on condition that the receiver is prepared to unravel that a bit (I'm convinced I already sent that once to someone). 2011/3/8 David Boyes dbo...@sinenomine.net On 3/8/11 2:21 PM, Ward, Mike S mw...@ssfcu.org wrote: Why not FTP it? Simple enough: Automating NJE transfer is trivial -- NJE is fire-and-forget in that the system daemons handle routing, retries, and guaranteed delivery (short of someone clearing spool for some stupid reason). If you've got the NJE connection, it's really, really easy to do this. NJE also doesn't require an active userid on the remote system to transfer files, and it doesn't tie up your userid while the file transfer is going on. Automating FTP transfer is a PITA, especially if you care if it actually arrives and/or if you hit a problem mid-transfer. Out of space errors (or any other trivial problem) are hard to recover from in a FTP script -- Kris Buelens, IBM Belgium, VM customer support -- Kris Buelens, IBM Belgium, VM customer support
Re: Sending files to JES
SPOOL PUN TO RSCS TAG DEV PUN zos SYSTEM PUNCH fn ft fm ( NOH Explanation: SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS knows to look at the tag data of the incoming files to decide what to do with them. TAG DEV PUN zos SYSTEM sets the tag data destination fields to node zos (replace with the NJE name of your zos system) SYSTEM, which is normally the JES input processor (SYSTEM is a magic word for NJE). PUNCH fn ft fm (NOH takes your virtual card deck stored in fn ft fm (must be RECFM F, LRECL 80) and punches it to RSCS without any special headers (the NOHeader parm). CP tags the virtual card deck with the information from the TAG command, and it ends up in RSCS' virtual reader. RSCS looks at the tag data, slurps up the file and sends it to zOS. All this is covered in the RSCS Users' Guide, albeit somewhat opaquely. Feel free to ask if you have more questions.
Re: Sending files to JES
Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through NJE. Neale On 3/8/11 12:34 PM, David Boyes dbo...@sinenomine.net wrote: SPOOL PUN TO RSCS TAG DEV PUN zos SYSTEM PUNCH fn ft fm ( NOH Explanation: SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS knows to look at the tag data of the incoming files to decide what to do with them. TAG DEV PUN zos SYSTEM sets the tag data destination fields to node zos (replace with the NJE name of your zos system) SYSTEM, which is normally the JES input processor (SYSTEM is a magic word for NJE). PUNCH fn ft fm (NOH takes your virtual card deck stored in fn ft fm (must be RECFM F, LRECL 80) and punches it to RSCS without any special headers (the NOHeader parm). CP tags the virtual card deck with the information from the TAG command, and it ends up in RSCS' virtual reader. RSCS looks at the tag data, slurps up the file and sends it to zOS. All this is covered in the RSCS Users' Guide, albeit somewhat opaquely. Feel free to ask if you have more questions.
Re: Sending files to JES
Also, Active means that the link has been started but the sign-on process has not been completed. The status must be Connect before a file can be transferred. Either JES has not started the link or there is a problem in the definition on either or both ends. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Neale Ferguson Sent: Tuesday, March 08, 2011 9:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through NJE. Neale On 3/8/11 12:34 PM, David Boyes dbo...@sinenomine.net wrote: SPOOL PUN TO RSCS TAG DEV PUN zos SYSTEM PUNCH fn ft fm ( NOH Explanation: SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS knows to look at the tag data of the incoming files to decide what to do with them. TAG DEV PUN zos SYSTEM sets the tag data destination fields to node zos (replace with the NJE name of your zos system) SYSTEM, which is normally the JES input processor (SYSTEM is a magic word for NJE). PUNCH fn ft fm (NOH takes your virtual card deck stored in fn ft fm (must be RECFM F, LRECL 80) and punches it to RSCS without any special headers (the NOHeader parm). CP tags the virtual card deck with the information from the TAG command, and it ends up in RSCS' virtual reader. RSCS looks at the tag data, slurps up the file and sends it to zOS. All this is covered in the RSCS Users' Guide, albeit somewhat opaquely. Feel free to ask if you have more questions.
Re: Sending files to JES
Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through NJE. The user part of the process is the same, though. In both cases, the file has to end up in RSCS' virtual reader; the transport between VM and z/OS is transparent to that process. If the z/OS system was running under the same VM instance, you'd just punch the file to the z/OS system userid after making sure the zOS system had a 2540 genned at address 00C and started in the JES startup proc. There you actually WANT the header, so you'd drop the NOH. If you wanted to skip the NJE part entirely, you can use FTP to send the job to the z/OS JES spool and retrieve your output (if your admin has enabled that service), but it's not nearly as nice as the NJE way.
Re: Sending files to JES
He didn't specify it was a job. That opens a whole new can of worms: JCL, pswd etc. Les David Boyes wrote: Alternatively, the TCPNJE add-on-extra to RSCS will allow submission through NJE. The user part of the process is the same, though. In both cases, the file has to end up in RSCS' virtual reader; the transport between VM and z/OS is transparent to that process. If the z/OS system was running under the same VM instance, you'd just punch the file to the z/OS system userid after making sure the zOS system had a 2540 genned at address 00C and started in the JES startup proc. There you actually WANT the header, so you'd drop the NOH. If you wanted to skip the NJE part entirely, you can use FTP to send the job to the z/OS JES spool and retrieve your output (if your admin has enabled that service), but it's not nearly as nice as the NJE way.
Re: Sending files to JES
On 3/8/11 1:00 PM, Les Koehler vmr...@tampabay.rr.com wrote: He didn't specify it was a job. That opens a whole new can of worms: JCL, pswd etc. Not the problem of the NJE transport. It's just got to get the file from system A to system B. Content and payload correctness are left as an exercise to the sender. 8-)
Re: Sending files to JES
That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? Thanks Scott From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of David Boyes Sent: Tuesday, March 08, 2011 12:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES SPOOL PUN TO RSCS TAG DEV PUN zos SYSTEM PUNCH fn ft fm ( NOH Explanation: SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS knows to look at the tag data of the incoming files to decide what to do with them. TAG DEV PUN zos SYSTEM sets the tag data destination fields to node zos (replace with the NJE name of your zos system) SYSTEM, which is normally the JES input processor (SYSTEM is a magic word for NJE). PUNCH fn ft fm (NOH takes your virtual card deck stored in fn ft fm (must be RECFM F, LRECL 80) and punches it to RSCS without any special headers (the NOHeader parm). CP tags the virtual card deck with the information from the TAG command, and it ends up in RSCS' virtual reader. RSCS looks at the tag data, slurps up the file and sends it to zOS. All this is covered in the RSCS Users' Guide, albeit somewhat opaquely. Feel free to ask if you have more questions.
Re: Sending files to JES
On Tuesday, 03/08/2011 at 02:00 EST, Shumate, Scott scshum...@bbandt.com wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? If you're sending to a TSO user, just SENDFILE fn ft TO user AT mvsnode. It gets packaged up in NETDATA format. If you're submitting a job, then you're limited to 80 bytes. If you are doing printing, then you need to use the PRINT command and a virtual printer (1403, 3800, or AFP). Tell us more about what you're trying to do. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Sending files to JES
Hi, Scott. The file you are trying to send is not too big, its record length exceeds what the PUNCH command supports. The maximum record length for the PUNCH command is 80 bytes. If what you are trying to send to z/OS (via RSCS) is a JCL file, make sure its lrecl is 80 and its recfm is fixed. Have a good one. DJ On 3/8/2011 12:56 PM, Shumate, Scott wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? Thanks Scott *From:* The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] *On Behalf Of *David Boyes *Sent:* Tuesday, March 08, 2011 12:34 PM *To:* IBMVM@LISTSERV.UARK.EDU *Subject:* Re: Sending files to JES SPOOL PUN TO RSCS TAG DEV PUN zos SYSTEM PUNCH fn ft fm ( NOH Explanation: SP PUN TO RSCS sets the destination of the PUNCH command on the VM side. RSCS knows to look at the tag data of the incoming files to decide what to do with them. TAG DEV PUN zos SYSTEM sets the tag data destination fields to node zos (replace with the NJE name of your zos system) SYSTEM, which is normally the JES input processor (SYSTEM is a magic word for NJE). PUNCH fn ft fm (NOH takes your virtual card deck stored in fn ft fm (must be RECFM F, LRECL 80) and punches it to RSCS without any special headers (the NOHeader parm). CP tags the virtual card deck with the information from the TAG command, and it ends up in RSCS' virtual reader. RSCS looks at the tag data, slurps up the file and sends it to zOS. All this is covered in the RSCS Users' Guide, albeit somewhat opaquely. Feel free to ask if you have more questions.
Re: Sending files to JES
I have 130 lrecl log file that is stored on operator's 191 disk. I need to get it over to our MVS side so we can store it in mobius. It appears since its greater than 80, I'm running into the problem described below. If I use send file, the file is jumbled on mvs side. Hopefully this is enough detail. Thanks Scott -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Tuesday, March 08, 2011 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES On Tuesday, 03/08/2011 at 02:00 EST, Shumate, Scott scshum...@bbandt.com wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? If you're sending to a TSO user, just SENDFILE fn ft TO user AT mvsnode. It gets packaged up in NETDATA format. If you're submitting a job, then you're limited to 80 bytes. If you are doing printing, then you need to use the PRINT command and a virtual printer (1403, 3800, or AFP). Tell us more about what you're trying to do. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Sending files to JES
Why not FTP it? -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Shumate, Scott Sent: Tuesday, March 08, 2011 1:16 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES I have 130 lrecl log file that is stored on operator's 191 disk. I need to get it over to our MVS side so we can store it in mobius. It appears since its greater than 80, I'm running into the problem described below. If I use send file, the file is jumbled on mvs side. Hopefully this is enough detail. Thanks Scott -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Tuesday, March 08, 2011 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES On Tuesday, 03/08/2011 at 02:00 EST, Shumate, Scott scshum...@bbandt.com wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? If you're sending to a TSO user, just SENDFILE fn ft TO user AT mvsnode. It gets packaged up in NETDATA format. If you're submitting a job, then you're limited to 80 bytes. If you are doing printing, then you need to use the PRINT command and a virtual printer (1403, 3800, or AFP). Tell us more about what you're trying to do. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Sending files to JES
Eventually you are going to find that files contain so many records (perhaps some with very large LRECLs) that using SENDFILE is no longer productive. Not only that, but SENDFILE (aka TRANSMIT or XMIT on TSO) and RECEIVE have significant CPU overhead, as they have to break wide files into files with records that can squeeze through your narrow 80-byte wide virtual punch, and then be reconstructed by RECEIVE at the target destination. FTP will do the trick, but it's difficult to script, and to handle bad return codes, etc. Download the free VMFTP package and you'll be on the way. The VMFTP package can be obtained from: Fran Hensler's excellent Slippery Rock University FTP site with the most recent updates as of 2009-03-13 at: http://zvm.sru.edu/~DOWNLOAD/ Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Shumate, Scott scshum...@bbandt.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/08/2011 01:15 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Sending files to JES I have 130 lrecl log file that is stored on operator's 191 disk. I need to get it over to our MVS side so we can store it in mobius. It appears since its greater than 80, I'm running into the problem described below. If I use send file, the file is jumbled on mvs side. Hopefully this is enough detail. Thanks Scott -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Tuesday, March 08, 2011 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES On Tuesday, 03/08/2011 at 02:00 EST, Shumate, Scott scshum...@bbandt.com wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? If you're sending to a TSO user, just SENDFILE fn ft TO user AT mvsnode. It gets packaged up in NETDATA format. If you're submitting a job, then you're limited to 80 bytes. If you are doing printing, then you need to use the PRINT command and a virtual printer (1403, 3800, or AFP). Tell us more about what you're trying to do. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Sending files to JES
Use the VM SENDFILE command: SENDFILE fn ft fm TO user AT zos On the z.OS side, use the TSO RECEIVE command to receive the file. SENDFILE takes the original file and encodes it to fit into a series of 80 byte cards, carrying enough metadata to reassemble the file in it's original form on the receiving system. This intermediate format (called NETDATA in the the NJE spec) is sent through the NJE network to the receiving system and is placed in spool. The RECEIVE command (both on VM and TSO) reads the file from spool, looks at the first 3 or 4 records and detects a flag that says I'm in NETDATA format. If that flag is present, RECEIVE reassembles the file to the original format and puts into the file you specified on the RECEIVE command. This approach might work for jobs too — older z/OS systems didn't understand NETDATA for jobs, so I gave you the VM Classic approach for that. I think newer z/Oses might understand it now; but… Jobs still have to be virtual cards on VM… Note if you have NJE code installed on your Suns or Linuxen, etc, this works great for dispatching work on them too….
Re: Sending files to JES
On 3/8/11 2:21 PM, Ward, Mike S mw...@ssfcu.org wrote: Why not FTP it? Simple enough: Automating NJE transfer is trivial -- NJE is fire-and-forget in that the system daemons handle routing, retries, and guaranteed delivery (short of someone clearing spool for some stupid reason). If you've got the NJE connection, it's really, really easy to do this. NJE also doesn't require an active userid on the remote system to transfer files, and it doesn't tie up your userid while the file transfer is going on. Automating FTP transfer is a PITA, especially if you care if it actually arrives and/or if you hit a problem mid-transfer. Out of space errors (or any other trivial problem) are hard to recover from in a FTP script
Re: Sending files to JES
On our VM systems, we had some processes that sent a CMS file embedded in an MVS job. The MVS job started TSO in batch to receive the file. At last that single job could carry multiple CMS files. As a result, the REXX code became less than easy to read for beginners. I can dig that up, on condition that the receiver is prepared to unravel that a bit (I'm convinced I already sent that once to someone). 2011/3/8 David Boyes dbo...@sinenomine.net On 3/8/11 2:21 PM, Ward, Mike S mw...@ssfcu.org wrote: Why not FTP it? Simple enough: Automating NJE transfer is trivial -- NJE is fire-and-forget in that the system daemons handle routing, retries, and guaranteed delivery (short of someone clearing spool for some stupid reason). If you've got the NJE connection, it's really, really easy to do this. NJE also doesn't require an active userid on the remote system to transfer files, and it doesn't tie up your userid while the file transfer is going on. Automating FTP transfer is a PITA, especially if you care if it actually arrives and/or if you hit a problem mid-transfer. Out of space errors (or any other trivial problem) are hard to recover from in a FTP script -- Kris Buelens, IBM Belgium, VM customer support
Re: Sending files to JES
That would be great. Can I take a look at it? Thanks Scott From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Kris Buelens Sent: Tuesday, March 08, 2011 3:47 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES On our VM systems, we had some processes that sent a CMS file embedded in an MVS job. The MVS job started TSO in batch to receive the file. At last that single job could carry multiple CMS files. As a result, the REXX code became less than easy to read for beginners. I can dig that up, on condition that the receiver is prepared to unravel that a bit (I'm convinced I already sent that once to someone). 2011/3/8 David Boyes dbo...@sinenomine.net On 3/8/11 2:21 PM, Ward, Mike S mw...@ssfcu.org wrote: Why not FTP it? Simple enough: Automating NJE transfer is trivial -- NJE is fire-and-forget in that the system daemons handle routing, retries, and guaranteed delivery (short of someone clearing spool for some stupid reason). If you've got the NJE connection, it's really, really easy to do this. NJE also doesn't require an active userid on the remote system to transfer files, and it doesn't tie up your userid while the file transfer is going on. Automating FTP transfer is a PITA, especially if you care if it actually arrives and/or if you hit a problem mid-transfer. Out of space errors (or any other trivial problem) are hard to recover from in a FTP script -- Kris Buelens, IBM Belgium, VM customer support
Re: Sending files to JES
I got the send file to work. I can receive it from the spool on z/OS side. Thanks for everyone's help. Thanks Scott -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Mike Walter Sent: Tuesday, March 08, 2011 2:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES Eventually you are going to find that files contain so many records (perhaps some with very large LRECLs) that using SENDFILE is no longer productive. Not only that, but SENDFILE (aka TRANSMIT or XMIT on TSO) and RECEIVE have significant CPU overhead, as they have to break wide files into files with records that can squeeze through your narrow 80-byte wide virtual punch, and then be reconstructed by RECEIVE at the target destination. FTP will do the trick, but it's difficult to script, and to handle bad return codes, etc. Download the free VMFTP package and you'll be on the way. The VMFTP package can be obtained from: Fran Hensler's excellent Slippery Rock University FTP site with the most recent updates as of 2009-03-13 at: http://zvm.sru.edu/~DOWNLOAD/ Mike Walter Aon Corporation The opinions expressed herein are mine alone, not my employer's. Shumate, Scott scshum...@bbandt.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 03/08/2011 01:15 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Sending files to JES I have 130 lrecl log file that is stored on operator's 191 disk. I need to get it over to our MVS side so we can store it in mobius. It appears since its greater than 80, I'm running into the problem described below. If I use send file, the file is jumbled on mvs side. Hopefully this is enough detail. Thanks Scott -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Alan Altmark Sent: Tuesday, March 08, 2011 2:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Sending files to JES On Tuesday, 03/08/2011 at 02:00 EST, Shumate, Scott scshum...@bbandt.com wrote: That works great. Now I'm running into a new problem. The file I'm sending is too big. I get the following message. DMSPUN044E Record exceeds allowable maximum Any ideas how I can get around this? If you're sending to a TSO user, just SENDFILE fn ft TO user AT mvsnode. It gets packaged up in NETDATA format. If you're submitting a job, then you're limited to 80 bytes. If you are doing printing, then you need to use the PRINT command and a virtual printer (1403, 3800, or AFP). Tell us more about what you're trying to do. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
