Re: Can a DDMF point to localhost?

Rereading my reply, I want to clarify the possibly misleading comment that there is no support for a member name, which the ALIAS accomplishes; somewhat clarified by the later statement about the ability to change the DDM file to point to whatever file.mbr using the nonstandard file naming. Note that the ALIAS is not _created_ in a manner which makes the DDMF act like a redirect to a local file *and* the member name specified by the ALIAS; i.e. the former statement about "no support" for the member name.

The DDMF can support a specific member, and it is really rather daft that the DDMFile as implementation object does not just get created that way in the first place. And the CHGDDMF is currently allowed to make the ALIAS work as redirection to a local file with the named member. But while the CHGDDMF is not restricted against the DDMF per its merely being an implementation object, I do not suspect the change request is [intended to be] full supported; i.e. the DDM *FILE object need not be created for a CREATE ALIAS in the future, as the ALIAS could be implemented as _only_ an entry in the catalog like most any other SQL RDBMS. Thus I would recommend against coding to the CHGDDMF of an ALIAS in order to effect OPNDBF & DSPPFM to work like the SQL ALIAS.

But anyhow... by using the nonstandard file name, with the naming of the form 'LIBNAME/FILENAME(MEMBERNAME)', that will direct the member-specific operations such as "open" database file member requests to access a specific member. Note that open requests which try to access a different member will fail with CPD9210 "Specified member cannot be used with member in RMTFILE" because the DDMFile is directing to a specific member, and the open is in conflict with that definitional request when naming another member name as a runtime request.

So if I perform the following SQL and CL, both the SQL ALIAS and DDMF for open activity will refer to the MEMBERNAME of the file SOMEDBFILE in library SOMELIB on the localhost:

CREATE ALIAS MYLIB/MYALIAS FOR SOMELIB/SOMEDBFILE(MEMBERNAME)

CHGDDMF FILE(MYLIB/MYALIAS)
RMTFILE(*NONSTD 'MYLIB/MYALIAS(MEMBERNAME)')
RMTLOCNAME(localhost *IP)

If the CREATE ALIAS had just created the DDMF expressly in the way the file is later modified by the CHGDDMF above, then both the SELECT FROM MYALIAS and the DSPPFM MYALIAS would access the data in the member MEMBERNAME [instead of member *FIRST; or in the case of DSPPFM, the member specified]. Of course because CHGDDMF is not restricted, changing the DDMF [for an ALIAS] to point to a *different* member than the ALIAS is also possible; that could be confusing :-)

Regards, Chuck

CRPence wrote:

The DDMFile is merely an "implementation object" for the SQL
ALIAS. Although the device file appears by DSPDDMF or DSPFD to
implement a DDMF pointing to a remote file at the
RMTLOCNAME(*LOCAL), note that there is support neither for a
member name which the ALIAS accomplishes nor for a Remote
Location Name of *LOCAL which appears. And although the DDM File
implementing the ALIAS could be changed using CHGDDMF to make
the device file generally functional to access a file by the name
listed in the NonStandard file name [or even a completely
different file], I would not recommend it even though that has no
effect on the file.mbr accessed when referencing the ALIAS. I am
unsure why CHGDDMF was not prevented from changing a DDMF which
exists only to implement an SQL ALIAS.

Regards, Chuck

Jose Antonio Salazar Montenegro wrote:

The DDM Server is up and working fine except for local access, be it by *SNA or *IP.

The SQL ALIAS worked nicely, it made the connection by SNA. But
I'd like to leave it all on a simple CL and plain CRTDDMF commands, but it's fine to have the ALIAS option as a last resort.

Mark S. Waterbury wrote:

Yes, it is possible. For example, I did this:

CRTDDMF FILE(QTEMP/MYDDMF) RMTFILE(MYLIB/MYFILE) RMTLOCNAME('127.0.0.1' *IP)

and this worked fine on my system.

Also, if you create an SQL ALIAS, it creates a DDMF "under
the covers".