Loading ...
Sorry, an error occurred while loading the content.

S0C1 abend

Expand Messages
  • kerravon86
    I wanted to see what happened when a C program called another C program. Here s the code: printf( hello there folks n ); printf( argc = %d n , argc); for (i =
    Message 1 of 16 , Apr 5, 2012
    • 0 Attachment
      I wanted to see what happened when a C program
      called another C program.

      Here's the code:

      printf("hello there folks\n");
      printf("argc = %d\n" , argc);
      for (i = 0; i < argc; i++)
      {
      printf("arg %d is <%s>\n", i, argv[i]);
      }
      if (strcmp(argv[1], "execute") == 0)
      {
      system("pdptest john smith");
      }
      printf("bye for now\n");

      And here's what it prints:

      hello there folks
      argc = 4
      arg 0 is <PDPTEST>
      arg 1 is <execute>
      arg 2 is <aBc>
      arg 3 is <DeF>
      hello there folks
      argc = 3
      arg 0 is <PDPTEST>
      arg 1 is <john>
      arg 2 is <smith>
      bye for now

      As you can see, the "bye for now" from the caller
      has not been done, and instead I get a S0C1:

      http://tech.groups.yahoo.com/group/hercules-os380/files/output.txt

      I think the problem is that the called program
      has closed the file. Here's the JCL:

      //PDPTEST EXEC PGM=PDPTEST,PARM='execute aBc DeF'
      //STEPLIB DD DSN=&&LOADLIB,DISP=(OLD,PASS)
      //SYSPRINT DD SYSOUT=*,DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
      //SYSTERM DD SYSOUT=*
      //SYSABEND DD SYSOUT=*
      //SYSIN DD DUMMY

      But I was under the impression that since an ATTACH
      was being done, the called program was free to
      open (which seems to work) and close the file
      (SYSPRINT) without affecting the calling program.

      Regardless, I would like the above to work. Is it
      possible under MVS?

      Thanks. Paul.
    • mfnoel
      Looks to me like you re trying to run a 2nd copy of a non-reentrant program. I think it will work if you make two copies, and have the 1st run the 2nd...
      Message 2 of 16 , Apr 5, 2012
      • 0 Attachment
        Looks to me like you're trying to run a 2nd copy of a non-reentrant program. I think it will work if you make two copies, and have the 1st run the 2nd...

        --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@...> wrote:
        >
        > I wanted to see what happened when a C program
        > called another C program.
        >
        > Here's the code:
        >
        > printf("hello there folks\n");
        > printf("argc = %d\n" , argc);
        > for (i = 0; i < argc; i++)
        > {
        > printf("arg %d is <%s>\n", i, argv[i]);
        > }
        > if (strcmp(argv[1], "execute") == 0)
        > {
        > system("pdptest john smith");
        > }
        > printf("bye for now\n");
        >
        > And here's what it prints:
        >
        > hello there folks
        > argc = 4
        > arg 0 is <PDPTEST>
        > arg 1 is <execute>
        > arg 2 is <aBc>
        > arg 3 is <DeF>
        > hello there folks
        > argc = 3
        > arg 0 is <PDPTEST>
        > arg 1 is <john>
        > arg 2 is <smith>
        > bye for now
        >
        > As you can see, the "bye for now" from the caller
        > has not been done, and instead I get a S0C1:
        >
        > http://tech.groups.yahoo.com/group/hercules-os380/files/output.txt
        >
        > I think the problem is that the called program
        > has closed the file. Here's the JCL:
        >
        > //PDPTEST EXEC PGM=PDPTEST,PARM='execute aBc DeF'
        > //STEPLIB DD DSN=&&LOADLIB,DISP=(OLD,PASS)
        > //SYSPRINT DD SYSOUT=*,DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
        > //SYSTERM DD SYSOUT=*
        > //SYSABEND DD SYSOUT=*
        > //SYSIN DD DUMMY
        >
        > But I was under the impression that since an ATTACH
        > was being done, the called program was free to
        > open (which seems to work) and close the file
        > (SYSPRINT) without affecting the calling program.
        >
        > Regardless, I would like the above to work. Is it
        > possible under MVS?
        >
        > Thanks. Paul.
        >
      • Gerhard Postpischil
        ... DCBs after OPEN are associated with the TCB that requested the OPEN. TCBs in a tree are allowed some read and write access, but not a CLOSE, which must be
        Message 3 of 16 , Apr 5, 2012
        • 0 Attachment
          On 4/5/2012 7:48 AM, kerravon86 wrote:
          > As you can see, the "bye for now" from the caller
          > has not been done, and instead I get a S0C1:
          >
          > http://tech.groups.yahoo.com/group/hercules-os380/files/output.txt
          >
          > I think the problem is that the called program
          > has closed the file. Here's the JCL:

          DCBs after OPEN are associated with the TCB that requested the
          OPEN. TCBs in a tree are allowed some read and write access, but
          not a CLOSE, which must be performed by the same or a higher
          TCB. While the 0C1 appears due to a closed DCB in @@AWRITE, the
          called task could not have closed it. Notice that x'18' bytes
          are missing in the dump, overlapping the ZDCB work area, which
          looks weird; something may have clobbered or freed some of it.

          > But I was under the impression that since an ATTACH
          > was being done, the called program was free to
          > open (which seems to work) and close the file
          > (SYSPRINT) without affecting the calling program.
          >
          > Regardless, I would like the above to work. Is it
          > possible under MVS?

          That is correct, but it won't do what you want, since output
          lines will appear in incorrect sequence, depending on buffer
          size and number of IOBs. When I helped with MVSSUPA, I raised
          precisely this issue, but you didn't want to hear about it. For
          non-DASD input files, sharing is not feasible; for JES output
          files, the code would have to search the TCBDEB chain(s) to see
          whether the DD is open, and bypass OPEN and CLOSE and use a
          common ZDCB work area.

          For output in general, lower tasks would need to call the higher
          task's output routine, in order to keep the data synchronized. I
          believe you have the source for @PRINTER, and you can see how
          that handles multi-task writing.

          Gerhard Postpischil
          Bradford, VT
        • Gerhard Postpischil
          ... For a non-reentrant program, the ATTACH processing will just load a second copy into storage, exactly as it would handle a module with a different name.
          Message 4 of 16 , Apr 5, 2012
          • 0 Attachment
            On 4/5/2012 10:58 AM, mfnoel wrote:
            > Looks to me like you're trying to run a 2nd copy of a
            > non-reentrant program. I think it will work if you make two
            > copies, and have the 1st run the 2nd...

            For a non-reentrant program, the ATTACH processing will just
            load a second copy into storage, exactly as it would handle a
            module with a different name.

            Gerhard Postpischil
            Bradford, VT
          • mfnoel
            Obviously my earlier speculation was wrong. I just ran your test and it worked, as is! Wonder why it didn t work for you??
            Message 5 of 16 , Apr 5, 2012
            • 0 Attachment
              Obviously my earlier speculation was wrong. I just ran your test and it worked, as is! Wonder why it didn't work for you??

              --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@...> wrote:
              >
              > I wanted to see what happened when a C program
              > called another C program.
              >
              > Here's the code:
              >
              > printf("hello there folks\n");
              > printf("argc = %d\n" , argc);
              > for (i = 0; i < argc; i++)
              > {
              > printf("arg %d is <%s>\n", i, argv[i]);
              > }
              > if (strcmp(argv[1], "execute") == 0)
              > {
              > system("pdptest john smith");
              > }
              > printf("bye for now\n");
              >
              > And here's what it prints:
              >
              > hello there folks
              > argc = 4
              > arg 0 is <PDPTEST>
              > arg 1 is <execute>
              > arg 2 is <aBc>
              > arg 3 is <DeF>
              > hello there folks
              > argc = 3
              > arg 0 is <PDPTEST>
              > arg 1 is <john>
              > arg 2 is <smith>
              > bye for now
              >
              > As you can see, the "bye for now" from the caller
              > has not been done, and instead I get a S0C1:
              >
              > http://tech.groups.yahoo.com/group/hercules-os380/files/output.txt
              >
              > I think the problem is that the called program
              > has closed the file. Here's the JCL:
              >
              > //PDPTEST EXEC PGM=PDPTEST,PARM='execute aBc DeF'
              > //STEPLIB DD DSN=&&LOADLIB,DISP=(OLD,PASS)
              > //SYSPRINT DD SYSOUT=*,DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
              > //SYSTERM DD SYSOUT=*
              > //SYSABEND DD SYSOUT=*
              > //SYSIN DD DUMMY
              >
              > But I was under the impression that since an ATTACH
              > was being done, the called program was free to
              > open (which seems to work) and close the file
              > (SYSPRINT) without affecting the calling program.
              >
              > Regardless, I would like the above to work. Is it
              > possible under MVS?
              >
              > Thanks. Paul.
              >
            • kerravon86
              You got bye for now printed twice? Thanks. Paul.
              Message 6 of 16 , Apr 5, 2012
              • 0 Attachment
                You got "bye for now" printed twice?

                Thanks. Paul.





                --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@...> wrote:
                >
                > Obviously my earlier speculation was wrong. I just ran your test and it worked, as is! Wonder why it didn't work for you??
                >
                > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                > >
                > > I wanted to see what happened when a C program
                > > called another C program.
                > >
                > > Here's the code:
                > >
                > > printf("hello there folks\n");
                > > printf("argc = %d\n" , argc);
                > > for (i = 0; i < argc; i++)
                > > {
                > > printf("arg %d is <%s>\n", i, argv[i]);
                > > }
                > > if (strcmp(argv[1], "execute") == 0)
                > > {
                > > system("pdptest john smith");
                > > }
                > > printf("bye for now\n");
                > >
                > > And here's what it prints:
                > >
                > > hello there folks
                > > argc = 4
                > > arg 0 is <PDPTEST>
                > > arg 1 is <execute>
                > > arg 2 is <aBc>
                > > arg 3 is <DeF>
                > > hello there folks
                > > argc = 3
                > > arg 0 is <PDPTEST>
                > > arg 1 is <john>
                > > arg 2 is <smith>
                > > bye for now
                > >
                > > As you can see, the "bye for now" from the caller
                > > has not been done, and instead I get a S0C1:
                > >
                > > http://tech.groups.yahoo.com/group/hercules-os380/files/output.txt
                > >
                > > I think the problem is that the called program
                > > has closed the file. Here's the JCL:
                > >
                > > //PDPTEST EXEC PGM=PDPTEST,PARM='execute aBc DeF'
                > > //STEPLIB DD DSN=&&LOADLIB,DISP=(OLD,PASS)
                > > //SYSPRINT DD SYSOUT=*,DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
                > > //SYSTERM DD SYSOUT=*
                > > //SYSABEND DD SYSOUT=*
                > > //SYSIN DD DUMMY
                > >
                > > But I was under the impression that since an ATTACH
                > > was being done, the called program was free to
                > > open (which seems to work) and close the file
                > > (SYSPRINT) without affecting the calling program.
                > >
                > > Regardless, I would like the above to work. Is it
                > > possible under MVS?
                > >
                > > Thanks. Paul.
                > >
                >
              • kerravon86
                ... If they re not allowed to do a CLOSE, what happens when they try to do a CLOSE (and an OPEN for that matter)? ... Well I don t know anyone else doing
                Message 7 of 16 , Apr 5, 2012
                • 0 Attachment
                  --- In hercules-os380@yahoogroups.com, Gerhard Postpischil <gerhard@...> wrote:
                  >
                  > On 4/5/2012 7:48 AM, kerravon86 wrote:
                  > > As you can see, the "bye for now" from the caller
                  > > has not been done, and instead I get a S0C1:
                  > >
                  > > http://tech.groups.yahoo.com/group/hercules-os380/files/output.txt
                  > >
                  > > I think the problem is that the called program
                  > > has closed the file. Here's the JCL:
                  >
                  > DCBs after OPEN are associated with the TCB that requested the
                  > OPEN. TCBs in a tree are allowed some read and write access, but
                  > not a CLOSE, which must be performed by the same or a higher
                  > TCB.

                  If they're not allowed to do a CLOSE, what happens
                  when they try to do a CLOSE (and an OPEN for that
                  matter)?

                  > While the 0C1 appears due to a closed DCB in @@AWRITE, the
                  > called task could not have closed it.

                  Well I don't know anyone else doing closes.

                  > Notice that x'18' bytes
                  > are missing in the dump, overlapping the ZDCB work area, which
                  > looks weird; something may have clobbered or freed some of it.

                  I didn't notice x'18' bytes missing.

                  > > But I was under the impression that since an ATTACH
                  > > was being done, the called program was free to
                  > > open (which seems to work) and close the file
                  > > (SYSPRINT) without affecting the calling program.
                  > >
                  > > Regardless, I would like the above to work. Is it
                  > > possible under MVS?
                  >
                  > That is correct, but it won't do what you want, since output
                  > lines will appear in incorrect sequence, depending on buffer
                  > size and number of IOBs.

                  The lines appear to be in the correct sequence so
                  far, and I am happy that I have a responsibility
                  to make sure the files are not blocked.

                  > When I helped with MVSSUPA, I raised
                  > precisely this issue, but you didn't want to hear about it.

                  ... which allowed us to get a functioning product
                  onto the market for literally years. Note that even
                  now the C code doesn't exercise all the functionality
                  that exists in the assembler, and it will probably be
                  further years before it does.

                  If there's no way to overcome the S0C1, so be it.
                  The important thing is that the tools are available
                  for being able to self-improve.

                  > For
                  > non-DASD input files, sharing is not feasible; for JES output
                  > files, the code would have to search the TCBDEB chain(s) to see
                  > whether the DD is open, and bypass OPEN and CLOSE and use a
                  > common ZDCB work area.

                  What is meant to happen with JES if you don't bypass
                  the OPEN and CLOSE?

                  I don't think it is feasible to use a common ZDCB
                  area due to the EODAD pointing at the wrong
                  module.

                  > For output in general, lower tasks would need to call the higher
                  > task's output routine, in order to keep the data synchronized.

                  Wow. That sounds really nasty. The modules may be
                  written in different languages.

                  > I
                  > believe you have the source for @PRINTER, and you can see how
                  > that handles multi-task writing.

                  I didn't notice it, but I'm only after English at
                  the moment. I just want to understand the issue.

                  BFN. Paul.
                • mfnoel
                  hello there folks argc = 4 arg 0 is arg 1 is arg 2 is arg 3 is hello there folks argc = 3 arg 0 is arg 1 is
                  Message 8 of 16 , Apr 5, 2012
                  • 0 Attachment
                    hello there folks
                    argc = 4
                    arg 0 is <PDPTEST>
                    arg 1 is <execute>
                    arg 2 is <aBc>
                    arg 3 is <DeF>
                    hello there folks
                    argc = 3
                    arg 0 is <PDPTEST>
                    arg 1 is <john>
                    arg 2 is <smith>
                    bye for now
                    bye for now

                    and no abend...


                    --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@...> wrote:
                    >
                    > You got "bye for now" printed twice?
                    >
                    > Thanks. Paul.
                    >
                    >
                    >
                    >
                    >
                    > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                    > >
                    > > Obviously my earlier speculation was wrong. I just ran your test and it worked, as is! Wonder why it didn't work for you??
                    > >
                    > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                    > > >
                    > > > I wanted to see what happened when a C program
                    > > > called another C program.
                    > > >
                    > > > Here's the code:
                    > > >
                    > > > printf("hello there folks\n");
                    > > > printf("argc = %d\n" , argc);
                    > > > for (i = 0; i < argc; i++)
                    > > > {
                    > > > printf("arg %d is <%s>\n", i, argv[i]);
                    > > > }
                    > > > if (strcmp(argv[1], "execute") == 0)
                    > > > {
                    > > > system("pdptest john smith");
                    > > > }
                    > > > printf("bye for now\n");
                    > > >
                    > > > And here's what it prints:
                    > > >
                    > > > hello there folks
                    > > > argc = 4
                    > > > arg 0 is <PDPTEST>
                    > > > arg 1 is <execute>
                    > > > arg 2 is <aBc>
                    > > > arg 3 is <DeF>
                    > > > hello there folks
                    > > > argc = 3
                    > > > arg 0 is <PDPTEST>
                    > > > arg 1 is <john>
                    > > > arg 2 is <smith>
                    > > > bye for now
                    > > >
                    > > > As you can see, the "bye for now" from the caller
                    > > > has not been done, and instead I get a S0C1:
                    > > >
                    > > > http://tech.groups.yahoo.com/group/hercules-os380/files/output.txt
                    > > >
                    > > > I think the problem is that the called program
                    > > > has closed the file. Here's the JCL:
                    > > >
                    > > > //PDPTEST EXEC PGM=PDPTEST,PARM='execute aBc DeF'
                    > > > //STEPLIB DD DSN=&&LOADLIB,DISP=(OLD,PASS)
                    > > > //SYSPRINT DD SYSOUT=*,DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
                    > > > //SYSTERM DD SYSOUT=*
                    > > > //SYSABEND DD SYSOUT=*
                    > > > //SYSIN DD DUMMY
                    > > >
                    > > > But I was under the impression that since an ATTACH
                    > > > was being done, the called program was free to
                    > > > open (which seems to work) and close the file
                    > > > (SYSPRINT) without affecting the calling program.
                    > > >
                    > > > Regardless, I would like the above to work. Is it
                    > > > possible under MVS?
                    > > >
                    > > > Thanks. Paul.
                    > > >
                    > >
                    >
                  • kerravon86
                    Silly me! I thought I d try a 24-bit build to see if that s why yours was working, and it worked for me! Then I realised what was happening. With the 31-bit
                    Message 9 of 16 , Apr 5, 2012
                    • 0 Attachment
                      Silly me!

                      I thought I'd try a 24-bit build to see if that's
                      why yours was working, and it worked for me! Then
                      I realised what was happening. With the 31-bit
                      build the two invocations will be clobbering the
                      ATL memory! ie it's a known limitation of 31 bit.

                      So it looks like it's working as expected, so
                      that's great.

                      Note that once again I found that my output file
                      from Hercules has an old listing included:

                      ****A END JOB 2 TERMHERC ROOM 11.01.29
                      ****A END JOB 2 TERMHERC ROOM 11.01.29
                      ****A END JOB 2 TERMHERC ROOM 11.01.29
                      ****A END JOB 2 TERMHERC ROOM 11.01.29

                      ^L0000 PQEL 00000000 TCB 00A6C840 FLID 2800000A SVRB 00A6E5F0 CN

                      MIN FE24F8 NMIN 00FE2538 PMIN 00FE24B8 FQEL 00FFF980 LQEL 00FFF980
                      NQEL 00000000 PQEL 00000000 TCB 00A6C840 FLID 2800000A

                      MIN FE2538 NMIN 00FE2578 PMIN 00FE24F8 FQEL 00FFF968 LQEL 00FFF968
                      NQEL 00000000 PQEL 00000000 TCB 00A6C840 FLID 2800000A
                      ...
                      ****A END JOB 1 PDPMVS ROOM 3.38.29 AM
                      ****A END JOB 1 PDPMVS ROOM 3.38.29 AM


                      Thanks. Paul.





                      --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@...> wrote:
                      >
                      > hello there folks
                      > argc = 4
                      > arg 0 is <PDPTEST>
                      > arg 1 is <execute>
                      > arg 2 is <aBc>
                      > arg 3 is <DeF>
                      > hello there folks
                      > argc = 3
                      > arg 0 is <PDPTEST>
                      > arg 1 is <john>
                      > arg 2 is <smith>
                      > bye for now
                      > bye for now
                      >
                      > and no abend...
                      >
                      >
                      > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                      > >
                      > > You got "bye for now" printed twice?
                      > >
                      > > Thanks. Paul.
                      > >
                      > >
                      > >
                      > >
                      > >
                      > > --- In hercules-os380@yahoogroups.com, "mfnoel" <mikenoel37@> wrote:
                      > > >
                      > > > Obviously my earlier speculation was wrong. I just ran your test and it worked, as is! Wonder why it didn't work for you??
                      > > >
                      > > > --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@> wrote:
                      > > > >
                      > > > > I wanted to see what happened when a C program
                      > > > > called another C program.
                      > > > >
                      > > > > Here's the code:
                      > > > >
                      > > > > printf("hello there folks\n");
                      > > > > printf("argc = %d\n" , argc);
                      > > > > for (i = 0; i < argc; i++)
                      > > > > {
                      > > > > printf("arg %d is <%s>\n", i, argv[i]);
                      > > > > }
                      > > > > if (strcmp(argv[1], "execute") == 0)
                      > > > > {
                      > > > > system("pdptest john smith");
                      > > > > }
                      > > > > printf("bye for now\n");
                      > > > >
                      > > > > And here's what it prints:
                      > > > >
                      > > > > hello there folks
                      > > > > argc = 4
                      > > > > arg 0 is <PDPTEST>
                      > > > > arg 1 is <execute>
                      > > > > arg 2 is <aBc>
                      > > > > arg 3 is <DeF>
                      > > > > hello there folks
                      > > > > argc = 3
                      > > > > arg 0 is <PDPTEST>
                      > > > > arg 1 is <john>
                      > > > > arg 2 is <smith>
                      > > > > bye for now
                      > > > >
                      > > > > As you can see, the "bye for now" from the caller
                      > > > > has not been done, and instead I get a S0C1:
                      > > > >
                      > > > > http://tech.groups.yahoo.com/group/hercules-os380/files/output.txt
                      > > > >
                      > > > > I think the problem is that the called program
                      > > > > has closed the file. Here's the JCL:
                      > > > >
                      > > > > //PDPTEST EXEC PGM=PDPTEST,PARM='execute aBc DeF'
                      > > > > //STEPLIB DD DSN=&&LOADLIB,DISP=(OLD,PASS)
                      > > > > //SYSPRINT DD SYSOUT=*,DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
                      > > > > //SYSTERM DD SYSOUT=*
                      > > > > //SYSABEND DD SYSOUT=*
                      > > > > //SYSIN DD DUMMY
                      > > > >
                      > > > > But I was under the impression that since an ATTACH
                      > > > > was being done, the called program was free to
                      > > > > open (which seems to work) and close the file
                      > > > > (SYSPRINT) without affecting the calling program.
                      > > > >
                      > > > > Regardless, I would like the above to work. Is it
                      > > > > possible under MVS?
                      > > > >
                      > > > > Thanks. Paul.
                      > > > >
                      > > >
                      > >
                      >
                    • Gerhard Postpischil
                      ... The lower task is free to do any number of OPEN and CLOSE requests on its own DCBs; you were asking about the lower task closing the caller s DCB, which
                      Message 10 of 16 , Apr 5, 2012
                      • 0 Attachment
                        On 4/5/2012 2:41 PM, kerravon86 wrote:
                        > If they're not allowed to do a CLOSE, what happens
                        > when they try to do a CLOSE (and an OPEN for that
                        > matter)?

                        The lower task is free to do any number of OPEN and CLOSE
                        requests on its own DCBs; you were asking about the lower task
                        closing the caller's DCB, which would have resulted in an x14 or
                        x55 abend.

                        >> While the 0C1 appears due to a closed DCB in @@AWRITE, the
                        >> called task could not have closed it.
                        >
                        > Well I don't know anyone else doing closes.

                        If you look at the ZDCB area, it may not have gotten closed, but
                        clobbered. Note the 'SYSP' followed by garbage? An OPEN DCB does
                        not contain a DD name, and a closed one would have the complete
                        name.

                        >> Notice that x'18' bytes
                        >> are missing in the dump, overlapping the ZDCB work area, which
                        >> looks weird; something may have clobbered or freed some of it.
                        >
                        > I didn't notice x'18' bytes missing.

                        Dump line CCCE0 has sixteen bytes, and the next datum starts at
                        CCD08.

                        > If there's no way to overcome the S0C1, so be it.
                        > The important thing is that the tools are available
                        > for being able to self-improve.

                        The 0C1 didn't happen by magic, rather there must be a reason
                        for it. But since there isn't a program listing, it may be
                        difficult to find.

                        > What is meant to happen with JES if you don't bypass
                        > the OPEN and CLOSE?

                        For JES, unit record, and tape (i.e., everything except DASD) an
                        output request moves a record to a buffer (different buffers for
                        different DCBs). When the buffer is full, a WRITE is issued. If
                        program A produces lines A1 and A2, and then calls program B
                        that produces B1 and B2, your result would be B1, B2, A1, A2.
                        With non-JES output you could get the correct order by forcing
                        unblocked output; for JES, your records are transferred to an
                        Unprotected Buffer, usually about 4K, before being copied to
                        spool, so the problem cannot be avoided with distinct DCBs.

                        > I don't think it is feasible to use a common ZDCB
                        > area due to the EODAD pointing at the wrong
                        > module.

                        Output files don't use or need EODAD.

                        > Wow. That sounds really nasty. The modules may be
                        > written in different languages.

                        All the more reason for writing everything in assembler <G>

                        Gerhard Postpischil
                        Bradford, VT
                      • kerravon86
                        ... Then how do you explain that I m getting A1, A2, B1, B2 exactly like I want, for JES output? BFN. Paul.
                        Message 11 of 16 , Apr 5, 2012
                        • 0 Attachment
                          --- In hercules-os380@yahoogroups.com, Gerhard Postpischil <gerhard@...> wrote:
                          >
                          > For JES, unit record, and tape (i.e., everything except DASD) an
                          > output request moves a record to a buffer (different buffers for
                          > different DCBs). When the buffer is full, a WRITE is issued. If
                          > program A produces lines A1 and A2, and then calls program B
                          > that produces B1 and B2, your result would be B1, B2, A1, A2.

                          Then how do you explain that I'm getting A1, A2, B1, B2
                          exactly like I want, for JES output?

                          BFN. Paul.


                          > With non-JES output you could get the correct order by forcing
                          > unblocked output; for JES, your records are transferred to an
                          > Unprotected Buffer, usually about 4K, before being copied to
                          > spool, so the problem cannot be avoided with distinct DCBs.
                        • kerravon86
                          ... Printer files seem strange too - now it is producing lots of 0s. C: mvs380 prt dir /od Volume in drive C has no label. Volume Serial Number is 4ABA-BE3B
                          Message 12 of 16 , Apr 5, 2012
                          • 0 Attachment
                            --- In hercules-os380@yahoogroups.com, "kerravon86" <kerravon86@...> wrote:
                            >
                            > Note that once again I found that my output file
                            > from Hercules has an old listing included:
                            >
                            > ****A END JOB 2 TERMHERC ROOM 11.01.29
                            > ****A END JOB 2 TERMHERC ROOM 11.01.29
                            > ****A END JOB 2 TERMHERC ROOM 11.01.29
                            > ****A END JOB 2 TERMHERC ROOM 11.01.29
                            >
                            > ^L0000 PQEL 00000000 TCB 00A6C840 FLID 2800000A SVRB 00A6E5F0 CN
                            >
                            > MIN FE24F8 NMIN 00FE2538 PMIN 00FE24B8 FQEL 00FFF980 LQEL 00FFF980
                            > NQEL 00000000 PQEL 00000000 TCB 00A6C840 FLID 2800000A
                            >
                            > MIN FE2538 NMIN 00FE2578 PMIN 00FE24F8 FQEL 00FFF968 LQEL 00FFF968
                            > NQEL 00000000 PQEL 00000000 TCB 00A6C840 FLID 2800000A
                            > ...
                            > ****A END JOB 1 PDPMVS ROOM 3.38.29 AM
                            > ****A END JOB 1 PDPMVS ROOM 3.38.29 AM


                            Printer files seem strange too - now it is producing
                            lots of 0s.

                            C:\mvs380\prt>dir /od
                            Volume in drive C has no label.
                            Volume Serial Number is 4ABA-BE3B

                            Directory of C:\mvs380\prt

                            22/11/2011 08:42 PM 200 sed_rc_exceptions.bat
                            22/11/2011 08:44 PM 127 sed_rc_all.bat
                            02/01/2012 10:16 AM 48,870 prt00f-20120201_111515.txt
                            02/01/2012 10:16 AM 7,179 prt00e-20120201_111515.txt
                            02/01/2012 10:52 AM 1,472,790 prt00e-20120201_111744.txt
                            02/01/2012 10:52 AM 130,298 prt00f-20120201_111744.txt
                            02/01/2012 07:25 PM 7,179 prt00e-20120201_202516.txt
                            02/01/2012 10:09 PM 133,808 prt00f-20120201_202516.txt
                            24/03/2012 08:23 PM 665,676 prt00e-20122403_182554.txt
                            24/03/2012 08:23 PM 119,721 prt00f-20122403_182554.txt
                            06/04/2012 05:01 AM 663,731 prt00e-00000000.000000.txt
                            06/04/2012 05:01 AM 73,477 prt00f-00000000.000000.txt
                            06/04/2012 12:54 PM <DIR> .
                            06/04/2012 12:54 PM <DIR> ..
                            12 File(s) 3,323,056 bytes
                            2 Dir(s) 768,595,742,720 bytes free

                            C:\mvs380\prt>

                            BFN. Paul.
                          • Gerhard Postpischil
                            ... I don t want to. I haven t looked at HASP/JES2 code in ages, and it s quite possible that they now assign a single UBF based on the DD name, rather than
                            Message 13 of 16 , Apr 6, 2012
                            • 0 Attachment
                              On 4/5/2012 10:52 PM, kerravon86 wrote:
                              > Then how do you explain that I'm getting A1, A2, B1, B2
                              > exactly like I want, for JES output?

                              I don't want to. I haven't looked at HASP/JES2 code in ages, and
                              it's quite possible that they now assign a single UBF based on
                              the DD name, rather than the ACB?

                              Gerhard Postpischil
                              Bradford, VT
                            • kerravon86
                              ... Ok, so it s lucky that mvssupa was implemented the way it was, instead of having a convoluted mechanism for a problem that doesn t exist. I have another
                              Message 14 of 16 , Apr 7, 2012
                              • 0 Attachment
                                --- In hercules-os380@yahoogroups.com, Gerhard Postpischil <gerhard@...> wrote:
                                >
                                > On 4/5/2012 10:52 PM, kerravon86 wrote:
                                > > Then how do you explain that I'm getting A1, A2, B1, B2
                                > > exactly like I want, for JES output?
                                >
                                > I don't want to. I haven't looked at HASP/JES2 code in ages, and
                                > it's quite possible that they now assign a single UBF based on
                                > the DD name, rather than the ACB?

                                Ok, so it's lucky that mvssupa was implemented the way
                                it was, instead of having a convoluted mechanism for a
                                problem that doesn't exist.

                                I have another question though. I now realise that for
                                the standard files like SYSPRINT, the file should be
                                unbuffered/unblocked, so RECFM=V instead of RECFM=VB.
                                Is there a way of specifying that in the AOPEN call?
                                It looks to me like I can't:

                                *---------------------------------------------------------------------*
                                * GET USER'S DEFAULTS HERE, BECAUSE THEY MAY GET CHANGED
                                *---------------------------------------------------------------------*
                                L R5,PARM3 HAS RECFM code (0-FB 1-VB 2-U)

                                It would be good if I could define a:
                                //SYSPRINT DD SYSOUT=*
                                and not need to specify DCB information to force it
                                to be unblocked. But if someone is happy for that to
                                be blocked, then they can specify the DCB information
                                themselves.

                                On that topic, I have another (unrelated) question.

                                What happens when you allocate a new file, but don't
                                specify any DCB information? I believe the file
                                *doesn't* get RECFM=U/V/F by default, but instead
                                it gets marked (presumably in the VTOC) as
                                "unspecified".

                                Or more precisely, the dscb1.ds1recfm will be 0 and
                                thus not match any of these values:

                                #define DS1RECFF 0x80
                                #define DS1RECFV 0x40
                                #define DS1RECFU 0xc0
                                #define DS1RECFB 0x10

                                Correct?

                                Thanks. Paul.
                              • Greg Price
                                ... I m pretty sure that that for SYSOUT - and TSO terminal files - blocking is ignored, meaning that the I/O functions as unblocked. (This is because DCBBLKSI
                                Message 15 of 16 , Apr 7, 2012
                                • 0 Attachment
                                  On Sat, 07 Apr 2012 11:45:04 -0000, kerravon86 wrote:

                                  >I now realise that for
                                  >the standard files like SYSPRINT, the file should be
                                  >unbuffered/unblocked

                                  I'm pretty sure that that for SYSOUT - and TSO terminal
                                  files - blocking is ignored, meaning that the I/O functions
                                  as unblocked.

                                  (This is because DCBBLKSI is not referenced by those I/O
                                  mechanisms. JES I/O just sucks up the data as it is presented
                                  by the underlying ACB interface, and each QSAM PUT macro
                                  to a TSO terminal file results in a TPUT before control is
                                  returned to the application. The trouble with TPUT is that
                                  the data must reside below the line, so in z/OS COBOL
                                  SYSPRINT to TSO terminals has trouble because the latest
                                  COBOL (LE perhaps? Maybe. Maybe not. C and PL/I do not
                                  seem to have this trouble, IIRC.) uses the DCBE to request I/O
                                  buffers above the line. Makes debugging under TSO a pain.)

                                  If the file gets allocated to tape or disk, you'd probably
                                  want to have it blocked anyway, I'd imagine.

                                  Perhaps this means that no change is required?

                                  Cheers,
                                  Greg
                                • Gerhard Postpischil
                                  ... A RECFM on the DD overrides PARM3; both are treated as F/V/U; the B is added provided that the output device is not unit record. The test for unit record
                                  Message 16 of 16 , Apr 7, 2012
                                  • 0 Attachment
                                    On 4/7/2012 7:45 AM, kerravon86 wrote:
                                    > I have another question though. I now realise that for
                                    > the standard files like SYSPRINT, the file should be
                                    > unbuffered/unblocked, so RECFM=V instead of RECFM=VB.
                                    > Is there a way of specifying that in the AOPEN call?
                                    > It looks to me like I can't:
                                    >
                                    > *---------------------------------------------------------------------*
                                    > * GET USER'S DEFAULTS HERE, BECAUSE THEY MAY GET CHANGED
                                    > *---------------------------------------------------------------------*
                                    > L R5,PARM3 HAS RECFM code (0-FB 1-VB 2-U)
                                    >
                                    > It would be good if I could define a:
                                    > //SYSPRINT DD SYSOUT=*
                                    > and not need to specify DCB information to force it
                                    > to be unblocked. But if someone is happy for that to
                                    > be blocked, then they can specify the DCB information
                                    > themselves.

                                    A RECFM on the DD overrides PARM3; both are treated as F/V/U;
                                    the B is added provided that the output device is not unit
                                    record. The test for unit record may be modified to include a
                                    test for spooled data (cli ,8 / be ur to cli ,8 / bnh ur) to
                                    turn off blocking.

                                    > On that topic, I have another (unrelated) question.
                                    >
                                    > What happens when you allocate a new file, but don't
                                    > specify any DCB information? I believe the file
                                    > *doesn't* get RECFM=U/V/F by default, but instead
                                    > it gets marked (presumably in the VTOC) as
                                    > "unspecified".

                                    When no RECFM appears on the DD, the low two bits of the PARM3
                                    value are used - 00=F, 01-V, 10=U, 11=U). If the DSCB1 does not
                                    get set, then I have an error in setting JFCBTSDM (open merge
                                    control bits).

                                    > #define DS1RECFF 0x80
                                    > #define DS1RECFV 0x40
                                    > #define DS1RECFU 0xc0
                                    > #define DS1RECFB 0x10
                                    > Correct?

                                    There is also 0x20 for RECFM=D (ASCII tape).


                                    As for the 0C1, have you considered adding a PARM option to
                                    control AMODE?


                                    Gerhard Postpischil
                                    Bradford, VT
                                  Your message has been successfully submitted and would be delivered to recipients shortly.