ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Temporary job file.

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

  • Temporary job file.

    Hi!

    In a PF I have just fields containing the key of record of other files.
    In older days on the S36 I used a job file with the values needed to sort them before listing.

    I had something like // FILE NAME-JOB01,DISP-NEW,RETAIN-JOB,etc. between // LOAD and // RUN.

    How can this be done now?

    TIA
    Arnaldo

  • #2
    Re: Temporary job file.

    You can create temporary files in library QTEMP. The system discards them when the job ends.

    Comment


    • #3
      Re: Temporary job file.

      Thanks, Ted.

      Do I need a DDS or is CRTPF FILE(JobFile) and internal definition enough?

      Comment


      • #4
        Re: Temporary job file.

        Originally posted by argasoft36 View Post
        Do I need a DDS or is CRTPF FILE(JobFile) and internal definition enough?
        'Enough' for what?

        If you need an externally-described file, you'll need DDS or SQL DDL. If you only need a single-field program-described file, then CRTPF is enough.
        Tom

        There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

        Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

        Comment


        • #5
          Re: Temporary job file.

          Thanks, Tom.

          Do you mean I cannot have something like this?
          F-spec:
          - file length 70 - key length 6 KEYLOC(1)
          I-spec:
          - jobkey from 1 to 6
          - fld001 from 7 to 37
          - etc.

          Comment


          • #6
            Re: Temporary job file.

            Originally posted by argasoft36 View Post
            Do you mean I cannot have something like this?
            No, that's not what I mean. You can have something like that if it is what you need.

            But you asked a question:

            Do I need a DDS or is CRTPF FILE(JobFile) and internal definition enough?
            And you didn't finish the question. You need to tell us "...enough for {what}."

            We can't tell which is needed if we don't know how it will be used. From your last comment, it's possible that CRTPF could be "enough" for what you showed. I wouldn't do it that way, and I suspect that very few of the experienced members would do it that way.

            But it could work. It just doesn't seem to take future maintenance and other factors into consideration. But we don't know the whole story.
            Tom

            There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

            Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

            Comment


            • #7
              Re: Temporary job file.

              I would expand my horizon to think past the s36 and define my tables using DDL. Its all the craze with the kids today.
              Hunting down the future ms. Ex DeadManWalks. *certain restrictions apply

              Comment


              • #8
                Re: Temporary job file.

                Thanks to all.

                @Tom: Sorry, "enough" was meant in the sense if it may run that way.
                How else could it be done?
                What I'm writing actually is just for me, so no one else would maintain. In the same time I would like to learn something new.

                I want to expand my horizon, but I start from my S36 knowledge.

                Comment


                • #9
                  Re: Temporary job file.

                  Originally posted by argasoft36 View Post
                  Thanks, Tom.

                  Do you mean I cannot have something like this?
                  F-spec:
                  - file length 70 - key length 6 KEYLOC(1)
                  I-spec:
                  - jobkey from 1 to 6
                  - fld001 from 7 to 37
                  - etc.

                  CRTPF RCDLEN(xx) will suffice if you plan to use it as a program-described file.... UNLESS you need keyed access. Since you coded KEYLOC() on the F-spec, I'm assuming that you do.

                  So you'll need DDS/DDL for the file (or else you'll need to use the S/36 BLDFILE procedure)

                  I wonder why you're trying to make your new version run as much as possible like a S/36 version? Typically for a modern application, you'd try not to use temporary files or program-described files, etc.

                  Comment


                  • #10
                    Re: Temporary job file.

                    Thanks for reply.

                    I have a file with estimates where I record the address key and not the customer name.
                    To list customers by name in ascending order, along with other data, in the S36-days I used a keyed job file to do this, instead of putting data in an array, sort it, etc (especially because there was a limit of 64kB per program).

                    I use a free hosting that has no S36 area available, thus I cannot use BLDFILE or have // FILE NAME-XXX,DIPS-NEW,RETAIN-J etc.
                    Furthermore free hosting has a limited space (of course).

                    I figured out that one way could be:
                    - have a DDS for the job-file
                    - do a CRTPF FILE(mylib/job-file) SRCFILE(mylib/DDS-name) before calling the application using this job file
                    - do a DLTF FILE(mylib/job-file) after programme ends to avoid having a file with delete records only

                    Now I see that instead of creating the job-file in mylib, QTEMP can be used, so the DLTF is not necessary.
                    I understand also that DDS is not avoidable as I need a key.

                    P.S. As said, I'm trying to update from RPGII/SSP 7.0 so I refer to it to know how it changed.

                    Thanks for patience.

                    Comment


                    • #11
                      Re: Temporary job file.

                      Originally posted by argasoft36 View Post
                      Now I see that instead of creating the job-file in mylib, QTEMP can be used, so the DLTF is not necessary.
                      The S/36 was good for its time. I have fond memories of my S/34 and S/36 days.

                      I used RETAIN-J often for temporary files. The usual way I do the same sort of thing nowadays is to try to clear the file, then create it if it doesn't exist.

                      Code:
                      clrpfm qtemp/&TempFile                      
                      monmsg cpf3142 exec(do)                     
                         crtpf qtemp/&TempFile rcdlen(&RcdLength) 
                      enddo
                      I also often keep an empty template file that I can duplicate.

                      Code:
                      clrpfm  &OutFLib/&OutFName mbr(&OutFMbr)                           
                      monmsg  cpf3142 exec(do)                                           
                         crtdupobj  obj(JobLogData) fromlib(*libl) +                     
                                       objtype(*file) tolib(&OutFLib) newobj(&OutFName) +
                                       cst(*no) trg(*no)                                 
                      enddo
                      I doubt I'm the only person on these fora who worked with S/36 and still remembers much of it. As you make the change from the S/36 way of computing to modern computing, you can probably get a lot of answers here.

                      Comment


                      • #12
                        Re: Temporary job file.

                        Don't know if it would be moving you too far, but if you happen to know SQL (within RPG) you can join the two files and would not need a temporary file at all. Or as a somewhat smaller step you could use OPNQRYF in the CL before calling the RPG, again you don't have to worry about creating a temporary file. If you had to learn either of those two methods, SQL is definitely the way to go.

                        Comment


                        • #13
                          Re: Temporary job file.

                          Originally posted by Scott Klement View Post
                          ...a program-described file.... UNLESS you need keyed access. Since you coded KEYLOC() on the F-spec, I'm assuming that you do.
                          I've never needed to use KEYLOC() (and I'm not sure why anyone would want to nowadays), but I had understood that it was only meaningful for program-described files. So, why does it imply a need for DDS/DDL? After a couple seconds of thought, it makes sense that it's needed for the creation, and then, once created, it can be accessed as a program-described file.

                          But that also kind of implies that KEYLOC() has no meaningful purpose other than as documentation that could be misleading. Does it actually need to mark the key location correctly? I should code up a test and answer it myself, but this thread has already taken more time than it should.

                          Nevermind.
                          Tom

                          There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

                          Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?

                          Comment


                          • #14
                            Re: Temporary job file.

                            Thanks to all.

                            Comment


                            • #15
                              Re: Temporary job file.

                              I use CRTDUPOBJ to create a copy of the file in QTEMP. That way the CL has no need to CRTPF or anything of that nature - and the file is available for compile purposes... but for it to work you need to have QTEMP towards the top of your library list - or at least above your data libraries *OR* an OVRDBF executed prior to opening it. I much prefer the former, some shops rather have QTEMP towards the end for various reasons.

                              Comment

                              Working...
                              X