| Author |
Message
|
| akashdwolf |
 Posted: Thu Sep 20, 2018 6:35 am Post subject: Unable to read a file From a remote mainframe server |
 |
|
Apprentice
Joined: 09 Feb 2017
Posts: 28
Location: Mumbai
|
I am trying to read a file using FileRead Node from a mainframe FTP Server.
------------------------------------------------------------------------------------
Configuration 1.
Basic Property:
Input Directory:/iib_support/JBL(local Broker server directory)
FileName:Q1(This file is present on the mainfram path 'TST.D7EZ.JBLSPP')
FTP Property:
Remote transfer is ticked
ServerDirectory: 'TST.D7EZ.JBLSPP' (mainframe FTP Server path)
Server and Port: d7vipac.shipments.jbl.com:21
SecurityIdentity:JBLSecurityIdentity
So 'TST.D7EZ.JBLSPP' is the mainframe path and Q1 is the file name.
----------------------------------------------------------------
When I run the code on IIB Server I can see 0KB size file is created
on /iib_support/JBL(local Broker server directory)
but my actual file Q1 which is present on the mainfram FTP server
d7vipac.shipments.jbl.com is having data in it.
-------------------------------------------------------------------------------
First I thought that maybe it is not reading the file from the remote FTP Server but creating one with same name that I have mentioned in the File Name property
so just to confirm this I gave a wrong file name
so I changed the below configuration:
Configuration 2.
Basic Property:
FileName:Q2(this file was not present on the remote server) so the got output from the NoMatchTerminal.
Below is the log for that:
LocalEnvironment
File
Read
Directory:CHARACTER:/iib_support/JBL
Name:CHARACTER:
TimeStamp:CHARACTER:20180920_132733_210800
Offset:INTEGER:0
EndOfFile:BOOLEAN:true
Delimiter:UNKNOWN:null
IsEmpty:BOOLEAN:false
NoMatchReason:CHARACTER:NoFile
Wildcard
WildcardMatch:UNKNOWN:null
This confirms that with configuration 2 it is not able to locate the file since it was not present on the FTP Server.
But the configuration 1 which was correct,it just places a 0KB file on the Broker server path /iib_support/JBL and tries to read files from there after the first execution,that makes no sense.
Please suggest something. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Sep 20, 2018 6:51 am Post subject: Re: Unable to read a file From a remote mainframe server |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| akashdwolf wrote: |
So 'TST.D7EZ.JBLSPP' is the mainframe path and Q1 is the file name.
|
No it isn't - that's a mainframe DSN (Data Set Name) and is the actual name of the file. The mainframe z/OS has no concept of directory, files are grouped by the first qualifier.
So you're getting a 0kb file because it can find the file (TST.D7EZ.JBLSPP) but can't then resolve anything to transfer.
Go back to whoever told you there was a "file" called Q1 inside that DSN and ask them was exactly they mean. The most plausible solution is that the DSN is a PDS (Partitioned Data Set) and one of the members is supposed to be called Q1. Get them to prove that such a member really exists.
If they want you to transfer the contents of the named file (or the latest copy of the named file, which they might refer to as a GDG), use that as the file name and leave the directory blank.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| akashdwolf |
| Posted: Thu Sep 20, 2018 7:38 am Post subject: |
|
|
Apprentice
Joined: 09 Feb 2017
Posts: 28
Location: Mumbai
|
Thanks for reply victor,
Please suggest based on the below FTP details:
[adminuser@jblesbrac01 ~]$ ftp d7vipac.shipments.jbl.com 21
Connected to d7vipac.shipments.jbl.com (165.26.209.4).
220-FTPD1 IBM FTP CS V2R1 at D7BLUEC, 15:27:04 on 2018-09-18.
220 Connection will close if idle for more than 50 minutes.
Name (d7vipac.shipments.jbl.com:adminuser): RIPJBLS
331 Send password please.
Password:
230 RIPJBLS is logged on. Working directory is "RIPJBLS .".
Remote system type is MVS.
ftp> pwd
257 "'RIPJBLS .'" is working directory.
ftp> cd TST
250 "RIPJBLS .TST." is the working directory name prefix.
ftp> cd D7EZ
250 "RIPJBLS .TST.D7EZ." is the working directory name prefix.
ftp> cd JBLSPP
250 "RIPJBLS .TST.D7EZ.JBLSPP." is the working directory name prefix.
ftp> dir
227 Entering Passive Mode (165,26,209,4,58,229)
550 No data sets found.
ftp> cd Q1
250 "RIPJBLS .TST.D7EZ.JBLSPP.Q1." is the working directory name prefix.
And on Baisc Property tab Input Server directory if I leave it blank then Broker gives Invalid directory so I need to pass something there. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 20, 2018 7:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| akashdwolf wrote: |
| Thanks for reply victor |
And thank you for spelling my name wrong.
| akashdwolf wrote: |
| Please suggest based on the below FTP details: |
A better suggestion would come from the owners of that file and/or the administrators of the mainframe ftp service.
| akashdwolf wrote: |
250 "RIPJBLS .TST.D7EZ.JBLSPP.Q1." is the working directory name prefix. |
I can't help noticing this is a different DSN to the one you first posted.
I would first suggest using RIPJBLS.TST.D7EZ.JBLSPP as the remote directory. If (or when) this gives you the same result, repeat the steps you posted on the ftp command line and try to get Q1 manually from the RIPJBLS.TST.D7EZ.JBLSPP directory. If (or when) this gives you the same result as the IIB transfer, go to the DSN owner and ask them to actually show you this Q1 file through the Browse function of an ISPF panel (option 3.4 on an OOTB ISPF configuration). Obtain a screenshot. Get them to show the RECFM of the file and obtain another screenshot. Post both screenshots here, or ask the guy who owns the ftp server on the mainframe how it maps those details and exposes them to an inbound ftp request.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| akashdwolf |
| Posted: Fri Sep 21, 2018 10:28 am Post subject: |
|
|
Apprentice
Joined: 09 Feb 2017
Posts: 28
Location: Mumbai
|
Thanks Vitor!!!
Remote ServerDirectory:'TST.D7EZ.JBLSPP.'
File Name:Q1
This configuration worked and I am able to read the file on my dev environment.
But now when I am reading this file in UAT environment I am getting the below error:
ReadFlatFile1. SubmitProgramData_Flow. FtpService[d7vipac.shipments.jbl.com,CWD ''TST.D7EZ.JBLSPP.'']. No locks available. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 21, 2018 10:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| akashdwolf wrote: |
This configuration worked and I am able to read the file on my dev environment.
But now when I am reading this file in UAT environment I am getting the below error |
So what's different about the OS configuration of your UAT environment?
Because that's not an IIB error, that's IIB reporting an OS level error about being unable to allocate a file lock.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| akashdwolf |
| Posted: Fri Sep 28, 2018 12:25 pm Post subject: |
|
|
Apprentice
Joined: 09 Feb 2017
Posts: 28
Location: Mumbai
|
You were right Vitor.It was some access issue.
After I changed the input directory to /var/mqsi/ It worked.  |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 01, 2018 5:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| akashdwolf wrote: |
| After I changed the input directory to /var/mqsi/ It worked. |
The /var/mqsi directory is where the software stores internal objects. I'd not open that up enough that applications / users could write to it.
I'd also not want to put application files in there in case it fills / becomes corrupt / becomes locked and it hoses your broker.
Create another directory under /opt or /app, grant the access needed and drop files there.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
