Quantcast
Channel: IBM Mainframe Computers Forums
Viewing all 8500 articles
Browse latest View live

SYNCSORT :: RE: String after '.' (period) is not copying in output

$
0
0
Author: balaji81_k
Posted: Wed Aug 23, 2017 9:58 pm (GMT 5.5)

Hi Sergeyken,

Its printed like >>> and then blanks .
_________________
dear peoples,
i want to join these this group in order to
enrich my knowledge in mainframe.


All Other Mainframe Topics :: FTP data transfer from PC to Mainframe why different format.

$
0
0
Author: AJAYREDDY
Subject: FTP data transfer from PC to Mainframe why different format.
Posted: Wed Aug 23, 2017 9:59 pm (GMT 5.5)

Hi, I have 2 text files that are doing FTP from PC to Mainframe. Both the text files are in tabular column format (Heading and Detail rows). But 1 of the text file (see MYFILE.TEST.CODE1) is coming as data in only 1 line continuous. Whereas the other file (see MYFILE.TEST.CODE2) is coming as in tabular column. I need the MYFILE.TEST.CODE1 also to be in tabular column. Please let me know what could be the reason behind it. I tried putting spaces manually in text file after heading, deleting some chars in first line etc etc but still it is not working.

Both the files after FTP are generating as 256 VB.

Here are FTP parms and data in each file.
Code:

IP address                                                 
userid                                                   
password                                                         
cd myfolder\Invoices           
get CODE1.txt 'MYFILE.TEST.CODE1' (REPLACE 
quit                                                         


 BROWSE    MYFILE.TEST.CODE1             Line 0000000000 Col 001 080
 Command ===>                                                  Scroll ===> CSR
********************************* Top of Data *********************************
Line #.Source.Org #.Company Vendor Name.Company Vendor Site.Invoice Number.Invoice
******************************** Bottom of Data *******************************


IP address                                                 
userid                                                   
password                                                         
cd myfolder\Invoices           
get CODE2.txt 'MYFILE.TEST.CODE2' (REPLACE 
quit                   

 BROWSE    MYFILE.TEST.CODE2               Line 0000000000 Col 001 080
 Command ===>                                                  Scroll ===> CSR 
********************************* Top of Data **********************************
Line.Source.Org.Vendor.Site.Inv #.Date.Inv Sign.Inv Amt.Line Sign.Line Amt.Tax.P
1.BR.222.EXPRESS SOMETHING        ABC818299323.ISDO322815.20150320.+.139.85.+.13
2.MR.333.EXPRESS SOMETHING        DEF818299323.ISDO322815.20150320.+.139.85.+.13
3.VR.444.EXPRESS SOMETHING        GHI818299323.ISDO322815.20150320.+.139.85.+.13
4.UR.555.EXPRESS SOMETHING        MNO818299323.ISDO322815.20150320.+.139.85.+.13


Coded..which after ten years the user should know to do himself
_________________
Ajay

SYNCSORT :: RE: String after '.' (period) is not copying in output

$
0
0
Author: sergeyken
Posted: Wed Aug 23, 2017 10:01 pm (GMT 5.5)

balaji81_k wrote:
Hi Sergeyken,

Its printed like >>> and then blanks .

Check in hex if they are REAL blanks? You can also temporary convert your output field to hex, for debugging.

If they are, verify carefully your data, and all offsets/lengths.

Definitely you have some stupid typo somewhere.
There are no such things as miracles.
_________________
Tyrannosaurus-REXX

All Other Mainframe Topics :: RE: FTP data transfer from PC to Mainframe why different format.

$
0
0
Author: vasanthz
Posted: Wed Aug 23, 2017 10:10 pm (GMT 5.5)

The issue is with CR LF NL conversion.

On the PC, look at the HEX data of the two files.
Notepad++ has Hex plugin which lets you view the hex data.

Check if both the files have CRLF charaters at the end of each record.
_________________
My therapist told me "write letters to people you hate and then burn them".
Did that, but now I don't know what to do with the letters.

All Other Mainframe Topics :: RE: FTP data transfer from PC to Mainframe why different format.

$
0
0
Author: Robert Sample
Subject: Reply to: FTP data transfer from PC to Mainframe why different format.
Posted: Wed Aug 23, 2017 10:10 pm (GMT 5.5)

One possible reason is different line terminators. Unix uses the LF (line feed) as a new line indicator, while Windows uses CRLF (carriage return / line feed) and mainframes use record length instead of line terminators. Your problem, for example, could be caused if your FTP assumes CRLF for both files but CODE1.txt has Unix LF terminators only -- so as far as FTP is concerned, you are retrieving a single line from the other server. There are other possibilities, but that's usually the first place to look. There is a LOCSITE parameter that can be set for the appropriate line terminator.
_________________
TANSTAAFL

The first rule of code reuse is that the code needs to be worth re-using.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth

All Other Mainframe Topics :: RE: FTP data transfer from PC to Mainframe why different format.

$
0
0
Author: vasanthz
Posted: Wed Aug 23, 2017 10:19 pm (GMT 5.5)

Robert, I win!
_________________
My therapist told me "write letters to people you hate and then burn them".
Did that, but now I don't know what to do with the letters.

SYNCSORT :: RE: Sorting on text - but in non-alphabetic order

$
0
0
Author: Roy Ware
Subject: Reply to: Sorting on text - but in non-alphabetic order
Posted: Wed Aug 23, 2017 10:52 pm (GMT 5.5)

It's a 2000 byte record with nothing at the end, so I overlaid the last 2 bytes with the sequence number - worked like a charm.

I mentioned DB2 because it has a lovely statement (Case?) I used to use to order things like this.

Thanks for all the help folks!
icon_biggrin.gif

All Other Mainframe Topics :: RE: FTP data transfer from PC to Mainframe why different format.

$
0
0
Author: Robert Sample
Subject: Reply to: FTP data transfer from PC to Mainframe why different format.
Posted: Wed Aug 23, 2017 10:53 pm (GMT 5.5)

LOL, so you did!
_________________
TANSTAAFL

The first rule of code reuse is that the code needs to be worth re-using.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth


SYNCSORT :: RE: String after '.' (period) is not copying in output

$
0
0
Author: Rohit Umarjikar
Posted: Wed Aug 23, 2017 11:00 pm (GMT 5.5)

With your SORT CARD , you should get below output.
Code:
0111|ABC|888ABC.IUY

So you are not telling us everything accurate, please double check what you are doing.
_________________
Regards,
Rohit Umarjikar
"Knowledge is knowing that a tomato is a fruit, but Wisdom is knowing not to put it in a fruit salad."icon_razz.gif

SYNCSORT :: RE: String after '.' (period) is not copying in output

$
0
0
Author: balaji81_k
Posted: Wed Aug 23, 2017 11:12 pm (GMT 5.5)

Hi Sergeyken,

Yes i did a small logic issue in my sort . Now i corrected it and it is working fine.

Thanks
_________________
dear peoples,
i want to join these this group in order to
enrich my knowledge in mainframe.

SYNCSORT :: RE: String after '.' (period) is not copying in output

$
0
0
Author: balaji81_k
Posted: Wed Aug 23, 2017 11:16 pm (GMT 5.5)

Rohit Umarjikar wrote:
With your SORT CARD , you should get below output.
Code:
0111|ABC|888ABC.IUY

So you are not telling us everything accurate, please double check what you are doing.


Hi Rohit,
Sorry , Yes you are correct about the output . I do have one more BI field in between where the length is not correctly specified in my sort(which i have modified now) . Apologize for the wrong output posted
_________________
dear peoples,
i want to join these this group in order to
enrich my knowledge in mainframe.

All Other Mainframe Topics :: RE: FTP data transfer from PC to Mainframe why different format.

$
0
0
Author: AJAYREDDY
Subject: CR LF
Posted: Thu Aug 24, 2017 12:23 am (GMT 5.5)

Thanks Vasanth and Robert. The issue was CR LF. The Notepad ++ showed LF for CODE1 and CR LF for CODE2. The txt files are created by Company A on our server. We pick them up by Mainframe by FTP. So is there any Windows tool that converts automatically to CR LF format or else can we convert LF to CR LF by FTP parms?
_________________
Ajay

All Other Mainframe Topics :: RE: FTP data transfer from PC to Mainframe why different format.

$
0
0
Author: Robert Sample
Posted: Thu Aug 24, 2017 2:00 am (GMT 5.5)

If the mainframe is doing the FTP, add
Code:
QUOTE LOCSITE SBSENDEOL=LF
to your FTP subcommands before the GET. If the other system is doing the FTP, add
Code:
QUOTE SITE SBSENDEOL=LF
to its FTP subcommands before the PUT. LOCSITE is used when z/OS is driving the FTP; SITE when the other system drives the FTP -- the commands are otherwise the same.
_________________
TANSTAAFL

The first rule of code reuse is that the code needs to be worth re-using.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth

All Other Mainframe Topics :: RE: FTP data transfer from PC to Mainframe why different format.

$
0
0
Author: Nic Clouston
Posted: Thu Aug 24, 2017 2:46 pm (GMT 5.5)

There is a utility, DOS2UNIX, that will convert LF to CRLF or the other way around. I do not know if this runs under windows or unix or both or under Cygwin.

But the true solution is to get both files created with the same characters.
_________________
Regards
Nic

JCL & VSAM :: IDCAMS Allocate & Repro

$
0
0
Author: pahiker
Subject: IDCAMS Allocate & Repro
Posted: Thu Aug 24, 2017 7:28 pm (GMT 5.5)

I'm having a devil of a time trying to merge VSAM datasets. The problem is that the names of the datasets change daily, fortunately the names are stored in a file that I can access. So, what I did (and it worked during testing) is to create a file with ALLOCATE and REPRO commands, then take that file into IDCAMS.

The problem I am having, and know of no way around, is that the ALLOCATE command prefixes the file names with the job's user name, REPRO takes the name as it is entered.

According to Knowledge Center the prefix can be overridden with the USER parm in the JOB card, but USER has to be a valid user ID, not something generic like TEST. REPRO, as far as I can tell, has nothing similar. So I end up with:

ALLOC (MY.FILE) creates MYID.MY.FILE
REPRO only sees MY.FILE, there seems to be no way to get MYID into the front of the file name.

Does anyone have any ideas on how to get around this?


JCL & VSAM :: RE: IDCAMS Allocate & Repro

$
0
0
Author: enrico-sorichetti
Subject: Reply to: IDCAMS Allocate & Repro
Posted: Thu Aug 24, 2017 7:44 pm (GMT 5.5)

if You are using idcams , the manual will tell how to get rid of the prefix

if You are running the allocate thru TSO then PROFILE NOPREFIX will do
_________________
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort icon_cool.gif

JCL & VSAM :: RE: IDCAMS Allocate & Repro

$
0
0
Author: pahiker
Subject: Re: Reply to: IDCAMS Allocate & Repro
Posted: Thu Aug 24, 2017 7:46 pm (GMT 5.5)

enrico-sorichetti wrote:
if You are using idcams , the manual will tell how to get rid of the prefix

if You are running the allocate thru TSO then PROFILE NOPREFIX will do


I read the manual (KC) and could not find a way to get rid of the prefix, which is why I posted here.

JCL & VSAM :: RE: IDCAMS Allocate & Repro

$
0
0
Author: pahiker
Posted: Thu Aug 24, 2017 7:52 pm (GMT 5.5)

Let me be more specific, the manual says

Quote:
If the USER parameter is not in the JCL, no prefix is added to any data set name given by ALLOCATE.


I don't have a USER parameter in my JCL, but the ALLOCATE is still picking it up.

JCL & VSAM :: RE: IDCAMS Allocate & Repro

$
0
0
Author: PeterHolland
Posted: Thu Aug 24, 2017 8:22 pm (GMT 5.5)

Show the damned JCL and talk with the JES2 people if there is a JES2 exit implemented that uses the jobcard info to change the dsname.

JCL & VSAM :: RE: IDCAMS Allocate & Repro

$
0
0
Author: steve-myers
Posted: Thu Aug 24, 2017 8:29 pm (GMT 5.5)

pahiker wrote:
Let me be more specific, the manual says

Quote:
If the USER parameter is not in the JCL, no prefix is added to any data set name given by ALLOCATE.


I don't have a USER parameter in my JCL, but the ALLOCATE is still picking it up.

Unless the job is submitted from a real card reader (remember those?) the job is assigned to the implicit userid of the submitting job or TSO session. Yes, you can specify a different user, but you cannot specify no user.

The IDCAMS ALLOCATE command is not really an IDCAMS command. It is really a TSO command. The IDCAMS manual clearly states this.
Quote:
Access method services identifies the verb name ALLOCATE and attaches the terminal monitor program (TMP) that runs Time Sharing Option (TSO) commands in the background. The ALLOCATE command should be used only to allocate new data sets to the job step. If you use ALLOCATE through access method services for anything else (the handling of SYSOUT data sets, for example), you can get unpredictable results. Refer to z/OS TSO/E Programming Guide for additional information on using this command. Table 2 in topic 4.5 separates the parameters to that you should use under access method services from the parameters that cause unpredictable results.

As in TSO, if you do not want the standard prefix added to a data set name specified in most TSO command lines, you use single quotes around the data set name.

ALLOCATE FILE(SYSLIB) SHR DATASET('SYS1.MACLIB')

For consistency you can use this method with batch IDCAMS commands.

DEFINE CLUSTER(NAME('SYS1.MACLIB') ...

Viewing all 8500 articles
Browse latest View live


Latest Images