The additional information for the problem are:
1) FILE1 MEMBER OF A PDS LRECL=80. FB
2) FILE2 PS LRECL=210, FB
3) OUTPUT=FILE1+FILE2 PS,LRECL=210, FB
FILE1 contains the header data for SMTP protocol.
FILE2 is the attached file sentd via SMTP.
I need to merge FILE1 (LRECL 80, FB) with data file FILE2 (LRECL 210, FB) to obtain a PS (LRECL 210, RECFM=FB)-
I hope that anybodoy can help me.
Kind Regards.
Hilario Garcia
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
I thought I had already helped you. Anyway, you can use a
DFSORT/ICETOOL job that like this:
//S1 EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//IN1 DD DSN=pds(member),... (FB/80)
//IN2 DD DSN=... input file2 (FB/210)
//OUT DD DISP=(MOD,CATLG,DELETE),DSN=... output file (FB/210)
//TOOLIN DD *
COPY FROM(IN1) TO(OUT) USING(CTL1)
COPY FROM(IN2) TO(OUT)
//CTL1CNTL DD *
INREC OVERLAY=(210:X)
/*
Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
=> DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort
Hilario,
I think what you really want to do is send via SMTP a file. The best way
would be to use SAS EMAIL process if you have SAS or XMITP. Both of these
processes make sending email from the mainframe easy.
SAS is a product you pay for and it is part of the BASE SAS. XMITP is free.
Lizette
I follow your example, but didn't work. The error is produce on second sentence COPY:
ICE600I 0 DFSORT ICETOOL UTILITY RUN STARTED
ICE650I 0 VISIT http://www.ibm.com/storage/dfsort FOR ICETOOL PAPERS, EXAMPL
ICE632I 0 SOURCE FOR ICETOOL STATEMENTS: TOOLIN
ICE630I 0 MODE IN EFFECT: STOP
COPY FROM(INFILE0) TO(SORTOUT) USING(CTL0)
ICE606I 0 DFSORT CALL 0001 FOR COPY FROM INFILE0 TO SORTOUT USING CTL0CNT
ICE602I 0 OPERATION RETURN CODE: 00
COPY FROM(INFILE1) TO(SORTOUT) USING(CTL1)
ICE606I 0 DFSORT CALL 0002 FOR COPY FROM INFILE1 TO SORTOUT USING CTL1CNT
ICE602I 0 OPERATION RETURN CODE: 16
ICE601I 0 DFSORT ICETOOL UTILITY RUN ENDED - RETURN CODE: 16
May you help me ?
Kind Regards.
Hilario G.
Cheers, Martin
Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM
email: martin...@uk.ibm.com
Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
From:
"Hilario G." <lib...@GMAIL.COM>
To:
IBM-...@bama.ua.edu
Date:
19/07/2011 09:21
Subject:
Re: How to obtain a file bigger than 80 chars from two inputs file
Sent by:
IBM Mainframe Discussion List <IBM-...@bama.ua.edu>
Hello Michael,
Kind Regards.
Hilario G.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>I follow your example, but didn't work. The error is produce on second sentence COPY:
>
>
>May you help me ?
>
Hilario,
Frank Yaeger answered your question twice:
8 Jul 2011: http://groups.google.com/group/bit.listserv.ibm-main/msg/a86401246013dff5
18 Jul 2011: http://groups.google.com/group/bit.listserv.ibm-main/msg/a1126856589c67cd
The second file in Michael's example is RECFM=VB. This won't work (without modifications) for RECFM=FB files.
Norbert Friemel
Pardon for the previos e-mail. Your example runs correctly. I adjust some values and now it work.
Kind Regards.
Hilario G.
>FILE2 is the attached file sentd via SMTP.
Depending on what's in the file, you may need to encode it and send it
as a MIME attachment.
--
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)
Good suggestion. I haven't seen any data as to performance though. In the past dumping SMF was while not slow it wasn't fast either. Has IBM ever been able to speed it up? The log stream might just be the answer to my issue, has onyone come up with any numbers?
Ed
(btw, below is what I see from the archives - all the #39 stuff instead of single quotes)
> Sam,
>Good suggestion. I haven't seen any data as to performance though. In the past dumping SMF was while not slow it wasn't
>fast either. Has IBM ever been able to speed it up? The log stream might just be the answer to my issue, has onyone come up with any
>numbers?
Of course there have been numbers published by IBM and "speeding up" was
one of the main reasons this was done.
Here is a data and some verbiage from a SHARE presentation (session
2853, I think it was San Jose). View in fixed font...
---------+----------+----------+----------+----------+----------+
|Base run |Using 1 |split |mult |Mult+ dup |
|with manx |log |across 3 |streams + |30 and |
|dsns |stream |logstreams|dup typ30 |100:102 |
---------+----------+----------+----------+----------+----------+
CPU% | 86.56% | 86.19% | 87.05% | 86.34% | 86.95% |
---------+----------+----------+----------+----------+----------+
TOT DASD | | | | | |
I/O rate | 4643 | 3622 | 3387 | 3436 | 3256 |
---------+----------+----------+----------+----------+----------+
SMFLOGR | | | | | |
# of REQ | | 82769 | 90474 | 91879 | 149324 |
---------+----------+----------+----------+----------+----------+
SMF data | | | | | |
log rate | 17355.19 | 17010.23 | 17221.54 | 17199.62 | 34472.71 |
(rec/sec)| | | | | |
---------+----------+----------+----------+----------+----------+
SMF avg | | | | | |
rec len | 298.12 | 298.12 | 298.12 | 298.12 | 298.3 |
---------+----------+----------+----------+----------+----------+
SMF size | | | | | |
in MB | 1776.33 | 1741.02 | 1762.65 | 1760.40 | 3530.46 |
---------+----------+----------+----------+----------+----------+
Here we see some interesting comparisons between SMF recording
to MANx data sets versus log streams.
1) When using the same workload, log stream recording did not
cause any significant change in CPU utilization. Compared to the
work load itself, SMF was not a significant contributer.
2) The DASD I/O rate, however, was lower when using log streams.
System Logger creates larger write requests than SMF recording
to MANx data sets, resulting in greater efficiency in I/O.
3) Even when duplicating records to multiple log streams, the
effect of SMF recording was insignificant compared to the
workload.
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:ma...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
Atenciosamente / Regards / Saludos
Ituriel do Nascimento Neto
BANCO BRADESCO S.A.
4254 / DPCD Engenharia de Software
Sistemas Operacionais Mainframes
Tel: +55 11 4197-2021 R: 22021
Fax: +55 11 4197-2814
-----Mensagem original-----
De: IBM Mainframe Discussion List [mailto:IBM-...@bama.ua.edu] Em nome de Mark Zelden
Enviada em: quinta-feira, 22 de setembro de 2011 13:53
Para: IBM-...@bama.ua.edu
Assunto: Re: How to dumps all the SMF datasets automagically evertime
> Sam,
AVISO LEGAL <br>...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação.
LEGAL ADVICE<br>...This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void.
>Does the presentation shows CI size and BUFSPACE of MANx datasets ?
>
No. There chart has the obligatory "YMMV" disclaimer and states:
SMF Logger study using Trade6 on a z9 system with 16CPs (single image)
99.9% of the SMF records were type 102 records
But even if it is optimal, this is still better compared to "20 year old
technology" (words used in the presentation).
Mark
Ed