× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 17-Jul-2016 22:22 -0500, Booth Martin wrote:
On 16-Jul-2016 18:06 -0500, CRPence wrote:
On 15-Jul-2016 13:58 -0500, Troy Hyde wrote:
On 15-Jul-2016 09:16 -0500, CRPence wrote:
On 14-Jul-2016 17:25 -0500, Troy Hyde wrote:

One of our web programmers is creating a page that contains
among other things, a description of printers including the
IP address. She has been able to obtain all of the
information she needs via SQL except the IP address. <<SNIP>>

What SQL is currently being used to provide the information
about printer devices; i.e. what invocation provides the DEVD
information without including the IP address? <<SNIP>>

We have a configuration table in our package that has a row for
each printer. It contains information specific for our
workflows: headings, lines to advance, next check number, print
logo, etc, etc. All of the information that she has been asked to
put on the screen is contained in this table except the I.P.
address of the printer. That one piece of information is not
specific to our package but specific to the *DEVD. We could put
it in the table (and we probably will,) but that would mean that
if someone changes the device description _without_ changing the
table, the information is incorrect. <<SNIP>>

I see how dynamic reflection is probably better than trying to
store and maintain the value; avoiding the need to ensure
consistency between the actual device attribute and the
representation of that attribute in row data. Note however, that
there is the capability to intercept the [return from] the [Create
and\or the] Change Device Description {Printer} (CHGDEVPRT)
command(s); that could be used as a means to enable maintaining
accuracy between the device and the row data <<SNIP>>

I have reintroduced, into the above text [using USENET-style quoting], what should be relevant context, taken from prior messages in this topic thread.


The original poster's real problem is that one set of experts is
trying to figure a way to communicate with another set of experts.
That is, ExpertsA are dynamically looking to determine the IP
Address of specific printers, as assigned by ExpertsB.

Not sure I can see that as describing the scenario. What I see:

• SfwPkg as source of a database table with some non-device-specific configuration; i.e. the device is not created from the information stored in the table.
• ExpertsWeb have access via SQL to a configuration-table as part of a sfw-package; apparently this configuration-table has the PrtDev-Name, but not the PrtDev-IPaddr.
• ExpertsBackEnd have experience with configuring printer devices [CRTPRTDEV and CHGDEVPRT] and writing code to offer-up data to the EpertsWeb.

That wheel has been invented. For this problem it's called DNS. The
DNS specifies the IP Address attached to a specific name. Standard
stuff, easily configurable, understood by everyone involved.

So suppose that this specific-name [e.g. MyLanPrtDev07] is stored in [is used to configure] the PrtDev, instead of using the IP address [e.g. 192.68.0.07]. Awesome! We are not specifying the IP Address in the device; i.e. by-address is highly discouraged, as the DNS is best utilized to translate from name-to-address at run-time.

Why would anyone look to invent some new poorly understood solution?
(I say poorly understood because it's pretty clear from the various
postings.)

OK, so the use of the DNS has [awesomely] allowed avoiding the deprecated IP address. But that attribute of the PrtDev, being maintained separate from the configuration-table, persists; i.e. even if the configuration-table had included the host-name [aka remote system name] vs the ip-addr, then the same dilemma as presented by the OP, would remain.

A changed *DEVD, even if changed to communicate with a different TCP/IP host-name [rather than changed to communicate with a different TCP/IP address], *still* would not be reflected in the configuration-table that is being queried. Thus if the ExpertsWeb want to present the data from the configuration-table, correlated to the _currently defined host-name_ stored in the PrtDev [ignoring the IP address, because that could be dynamically obtained via DNS if\when needed], they still must depend on ExpertsBackEnd to generate that information.


200 lines of text?!?! Good grief!! I had no idea you would append
that many lines to one of your responses,

I included a code snippet that I felt was better offered inline than either an attachment or by redirection to code.midrange.com, despite taking almost half of those lines; perhaps that was excessive. Nonetheless...

Chuck. In the future I will check your replies and remove the
extraneous lines for you. Sorry; please accept my apologies.

Such checking, of what is being sent, should always be done, irrespective from whom was the quoted text; see:

[http://policy.midrange.com/mailing-lists/]
"midrange.com mailing lists are offered as a service to the IBM i technical community.

Guidelines for participation in the mailing lists are posted monthly.

The following, general rules, apply to all lists hosted here…

• When quoting messages, do not quote the entire message. Just quote the parts that are needed to make the appropriate references.
…"


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.