We have the MKDIR for /QNTC as part of our startup programs with the MONMSG.
Very Respectfully,
Michael Mayer
IBM I on Power System Admin.
IT Operations.
The Florida Bar
651 E. Jefferson St
Tallahassee, Florida 32399-2300
mmayer@xxxxxxxxxxxxxx
https://www.floridabar.org
Office: 850.561.5761
Cell: 518.641.8906
3. Best practice for establishing a QNTC path (Jason Aleksi)
4. RE: Best practice for establishing a QNTC path (Christopher Bipes)
5. RE: Best practice for establishing a QNTC path
(midrangel@xxxxxxxxxxxxxxxxx)
----------------------------------------------------------------------
message: 3
date: Thu, 3 Jun 2021 11:24:02 -0500
from: Jason Aleksi <jason.aleski@xxxxxxxxx>
subject: Best practice for establishing a QNTC path
I am looking for a better solution or a preferred best practice for establishing a QNTC path from our IBM i to a Windows File Share, each being on a different LAN subnet?
*Current Problem*
Our IBM i resides on a 192.168.0.0/24 subnet. Our new Windows File Server is on a 10.0.0.0/23 subnet. Both can ping and talk to each other. There are no firewalls between, just routing/networking. As I understand, QNTC will broadcast out to dynamically find its Network Neighbors (via network broadcast). However, with the new 10.0.0.0 subnets, the Dynamic Discovery broadcasts do not make it to the new servers due to the broadcast domain.
If we manually create the QNTC path using MKDIR DIR(?/QNTC/server?), everything works as it should (stream files, copies, etc.). However when the system IPLs, manually created QNTC paths are wiped out; thus the need to be recreated.
*Possible Solutions*
1) Create a CL script that runs MKDIR DIR(?/QNTC/server?) for each
remote file server as part of the startup IPL sequence.
2) Modify each CL/RPG program to check/create the link each time:
MKDIR DIR(?/QNTC/server?)
MONMSG CPFA0A0 /* Ignore if object already exists */
Are there any other methods or preferred best practices?
-JA-
------------------------------
message: 4
date: Thu, 3 Jun 2021 16:36:53 +0000
from: Christopher Bipes <chris.bipes@xxxxxxxxxxxxxxx>
subject: RE: Best practice for establishing a QNTC path
We use option 1. Our startup program does the MKDIR for all the SMB shares we need to access.
Chris Bipes
Director of Information Services
CrossCheck, Inc.
707.665-2100, ext. 1102
707.793.5700 FAX
chris.bipes@xxxxxxxxxxxxxxx
www.cross-check.com
Notice of Confidentiality: This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information.? If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited.? If you have received this e-mail in error, please immediately notify me by e-mail (by replying to this message) or telephone (noted above) and permanently delete the original and any copy of any e-mail and any printout thereof.? Thank you for your cooperation with respect to this?matter.
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jason Aleksi
Sent: Thursday, June 3, 2021 9:24 AM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Best practice for establishing a QNTC path
I am looking for a better solution or a preferred best practice for establishing a QNTC path from our IBM i to a Windows File Share, each being on a different LAN subnet?
*Current Problem*
Our IBM i resides on a 192.168.0.0/24 subnet. Our new Windows File Server is on a 10.0.0.0/23 subnet. Both can ping and talk to each other. There are no firewalls between, just routing/networking. As I understand, QNTC will broadcast out to dynamically find its Network Neighbors (via network broadcast). However, with the new 10.0.0.0 subnets, the Dynamic Discovery broadcasts do not make it to the new servers due to the broadcast domain.
If we manually create the QNTC path using MKDIR DIR(?/QNTC/server?), everything works as it should (stream files, copies, etc.). However when the system IPLs, manually created QNTC paths are wiped out; thus the need to be recreated.
*Possible Solutions*
1) Create a CL script that runs MKDIR DIR(?/QNTC/server?) for each
remote file server as part of the startup IPL sequence.
2) Modify each CL/RPG program to check/create the link each time:
MKDIR DIR(?/QNTC/server?)
MONMSG CPFA0A0 /* Ignore if object already exists */
Are there any other methods or preferred best practices?
-JA-
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
------------------------------
message: 5
date: Thu, 3 Jun 2021 11:47:32 -0500
from: <midrangel@xxxxxxxxxxxxxxxxx>
subject: RE: Best practice for establishing a QNTC path
Nearly 100% of my customers also use #1.
I'm not sure the broadcast process is one to be trusted anymore in this world of malware. I'm certainly questioning if direct informed action is better than "oh look, there's another server/share to look at" OK a little snarky but when you think it out, it makes sense.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Christopher Bipes
Sent: Thursday, June 3, 2021 11:37 AM
To: 'midrange-l@xxxxxxxxxxxxxxxxxx' <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: RE: Best practice for establishing a QNTC path
We use option 1. Our startup program does the MKDIR for all the SMB shares we need to access.
Chris Bipes
Director of Information Services
CrossCheck, Inc.
707.665-2100, ext. 1102
707.793.5700 FAX
chris.bipes@xxxxxxxxxxxxxxx
www.cross-check.com
Notice of Confidentiality: This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify me by e-mail (by replying to this message) or telephone (noted above) and permanently delete the original and any copy of any e-mail and any printout thereof. Thank you for your cooperation with respect to this matter.
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jason Aleksi
Sent: Thursday, June 3, 2021 9:24 AM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Best practice for establishing a QNTC path
I am looking for a better solution or a preferred best practice for establishing a QNTC path from our IBM i to a Windows File Share, each being on a different LAN subnet?
*Current Problem*
Our IBM i resides on a 192.168.0.0/24 subnet. Our new Windows File Server is on a 10.0.0.0/23 subnet. Both can ping and talk to each other. There are no firewalls between, just routing/networking. As I understand, QNTC will broadcast out to dynamically find its Network Neighbors (via network broadcast). However, with the new 10.0.0.0 subnets, the Dynamic Discovery broadcasts do not make it to the new servers due to the broadcast domain.
If we manually create the QNTC path using MKDIR DIR(?/QNTC/server?), everything works as it should (stream files, copies, etc.). However when the system IPLs, manually created QNTC paths are wiped out; thus the need to be recreated.
*Possible Solutions*
1) Create a CL script that runs MKDIR DIR(?/QNTC/server?) for each
remote file server as part of the startup IPL sequence.
2) Modify each CL/RPG program to check/create the link each time:
MKDIR DIR(?/QNTC/server?)
MONMSG CPFA0A0 /* Ignore if object already exists */
Are there any other methods or preferred best practices?
-JA-
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
------------------------------
Subject: Digest Footer
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) digest list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://amazon.midrange.com
------------------------------
End of MIDRANGE-L Digest, Vol 20, Issue 806
*******************************************
________________________________
Please note: Florida has very broad public records laws. Many written communications to or from The Florida Bar regarding Bar business may be considered public records, which must be made available to anyone upon request. Your e-mail communications may therefore be subject to public disclosure.
midrange.com
