Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Write to a remote physical file

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Write to a remote physical file

    What were your problems with DDM? Dave

  • #2
    Write to a remote physical file

    Hello, I have a cobol program which write some record to a file (see code) I create the file (TESTRMT) with this SQL statement : CREATE TABLE QGPL/TESTRMT (NAME FOR COLUMN NOM CHAR (1 ) NOT NULL WITH DEFAULT) When I run the program, it runs well. But now I create the same file on a remote host and create the DDMF. Then I remove the local file and I run the program again to write records to the remote host but I have the file status 90 (file not found). But when I use DFU, I can put records and can clear it with CLRPFM command. Thanks, MT
    Code

    Comment


    • #3
      Write to a remote physical file

      It sounds to me like your problem is not with your COBOL code, but perhaps with your CL. Make sure that you are pointing to the correct file in the correct library. Your COBOL program should react to a DDMF as if it were a local file on the local system. That is the beauty of DDM. The HLL is not aware that in actuality the file is remote. BTW, make sure that QUSER has the correct object authority on the remote system. Dave

      Comment


      • #4
        Write to a remote physical file

        File status 90 does not necessarily mean file not found. Check the messages in your job log to see if that helps identify the problem.

        Comment


        • #5
          Write to a remote physical file

          Now, my pgm can write to the remote file. What I try to do now is to use the SQL in cobol program but I have the message :
          File TESTRMT in QGPL not database file.
          TESTRMT is a *FILE with DDMF attribute. Is this possible to use SQL which write to a remote table without using "CONNECT TO" sql statement ? I don't want to use CONNECT because the database name, user and password are hardcoded in cobol program like CONNECT TO DB2TEST USING TATMON PASSWORD ???? Thanks, MT
          Code

          Comment


          • #6
            Write to a remote physical file

            tatmon wrote: > Is this possible to use SQL which write to a remote table without > using "CONNECT TO" sql statement ? I don't want to use CONNECT > because the database name, user and password are hardcoded in cobol > program like CONNECT TO DB2TEST USING TATMON PASSWORD ???? Can't you just prompt for the user profile name and password and then feed them to the program and use substitution host variables? Bill

            Comment


            • #7
              Write to a remote physical file

              Can you create an alias to a DDM file (SQL command CREATE ALIAS)? Then change your COBOL's SQL statements to refer to the alias instead of the DDM file?

              Comment


              • #8
                Write to a remote physical file

                I can't because it's a job which will run in batch

                Comment


                • #9
                  Write to a remote physical file

                  Hello everyone, I have a Cobol program which writes records to physical file on the same local iSeries. Now, I'd like to write the same records to a remote physical file (on another iSeries) without modifying the program. How can I do that ? I've tried to use a DDMF but no success. Thanks in advance. MT

                  Comment


                  • #10
                    Write to a remote physical file

                    No, it's impossible : CREATE ALIAS TAMSDEVF00/TSTALIAS FOR QGPL/TESTRMT File TESTRMT in QGPL not database file. SQL want a data base file. it can not create an alias to a DDMF.

                    Comment


                    • #11
                      Write to a remote physical file

                      tatmon wrote: > I can't because it's a job which will run in batch Why would running in batch be a problem? You can prompt for the user profile and password before the job is submitted. If this wouldn't work for some reason, what would be the ideal solution then? Bill

                      Comment

                      Working...
                      X