Announcement

Collapse
No announcement yet.

DSPJRN problem, need help

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

  • DSPJRN problem, need help

    I performed a DSPJRN command and specified outfile output. I wrote a program that reads the outfile and performs some processing. It worked flawlessly. We have separate development and production machines and use a change management tool to promote things to production. So, I had to create DDS for chg mgmt to be able to recreate the file. I used a well know file patch utility (DBU) to export the fields to the DDS. Now that the DSPJRN outfile and program have been moved to PROD, the DSPJRN command fails with the following message:
    Code:
    Additional Message Information
    
    Message ID . . . . . . : CPF9865 Severity . . . . . . . : 40
    Message type . . . . . : Diagnostic
    Date sent . . . . . . : 02/23/21 Time sent . . . . . . : 17:31:45
    
    Message . . . . : Format of output file CRMPJRNBT in library GWIKLE2 not
    valid.
    Cause . . . . . : The format of the output file for a display command is not
    the same as the format of the system-supplied output file.
    Recovery . . . : Specify a different data base name (OUTFILE parameter) and
    then try the request again.
    
    How can I recreate the outfile with DDS

  • #2
    I'm not sure why you created the DDS? Is there a reason you didn't copy the file to production?
    For the DSPJRN command, IBM has provided model files which you should copy and use for the output. The model files are of the form QASYxxJn. The xx relates to the entry type you are extracting (e.g. AF for authorisation failures, DO for delete operations etc). The n relates to the outfile format (e.g. 1 for *TYPE1, 2 for *TYPE2 etc).
    You should copy the model file to e.g. QTEMP and use that for the ouput of the DSPJRN command.

    Comment


    • #3
      Originally posted by john.sev99 View Post
      I'm not sure why you created the DDS? Is there a reason you didn't copy the file to production?
      The reason I created DDS was because our change management software doesn't support moving files, it expects to re-create them from DDS (It's crappy chg mgmt tool, I know, but that's a story for another day). When I created the files using the outfile support of the DSPJRN command, I exported the definition to DDS source member in expectation that the chg mgmt software would just re-create the file from the DDS and I could dump the DSPJRN output to the DDS generated file just like I did with the original outfile I created. So, somehow, I need to figure out a way to be able to dump the DSPJRN to a DDS generated file or see if the powers that be will allow us to go around our established processes (required by our IT audit) and just move the files to the production computer.

      I well aware that the easiest way would be to just move the files but I am trying to adhere to established guidelines

      Comment


      • #4
        Why do you need to create a file, Greg? The way I typically do this sort of thing is to make the program create the file in QTEMP. I don't keep a permanent file object. As for compiling the program that will read the file, I do what John said -- I write the program as if it will use the model file that IBM supplies, then I override IBM's model file to the file in QTEMP before the open.

        If you do it this way, you still have to promote the program from the test system to the production system thru your change management system, but you won't promote that file.

        Comment


        • #5
          Somehow, the file created in PROD isn't done the same way as DEV. You can try doing a CRTDUPOBJ of QSYS/QASYJSJx file to create the file instead of using DDS, if that's allowed. Is CRTPF the only allowed migration method? This problem can be easily solved. Show us the DSPJRN command (mainly the entry type, output type) to run, and the first few lines of your DDS.

          Comment


          • gregwga50
            gregwga50 commented
            Editing a comment
            As it turned out the tool I used to export the journaled outfile had a record format name QJORDJE3. This is what IBM assigned when I executed the DSPJRN OUTPUT(*OUTFILE) command. The tool I used to export to DDS put a different record format name in the DDS. Once I changed the DDS so the record format name was also QJORDJE3 and recreated the file, it worked fine dumping the DSPJRN results to the outfile.

            I don't like having to use DDS and a compiled outfile but our change mgmt software likes it better.

        • #6
          Great to hear that, Greg . I knew this can be easily solved. And you figured it out yourself. I was trying to solve it within the constraints you are facing. (JE3 was really weird! I need to do my own test to understand more!! )

          Comment


          • #7

            When OUTFILFMT is *TYPE3, then the DSPJRN command creates the outfile with record format QJORDJE3
            Click image for larger version

Name:	IBM1.jpg
Views:	0
Size:	56.0 KB
ID:	154999


            Comment


            • #8
              Got it. I thought so, except that the model files I have seen for the many years past are just having JE, J4 and J5 suffixes, so in my mind, I only think of TYPE1, TYPE4 and TYPE5 being supported! Well, I learnt something. I only use TYPE1 and TYPE5, since they are the two extremes. Have a nice day.

              Comment

              Working...
              X