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

prefixing rules

Expand Messages
  • kerravon86
    I assume when a TSO program does an open of fred.c that it knows that it needs to add the SYSPREF on itself and do a dynalloc of it. I ll thus need to add that
    Message 1 of 7 , Jul 6, 2011
    • 0 Attachment
      I assume when a TSO program does an open of
      fred.c that it knows that it needs to add the
      SYSPREF on itself and do a dynalloc of it.
      I'll thus need to add that functionality to
      PDPCLIB.

      For PDOS, I would expect that profile noprefix
      is in force most of the time, allowing it to
      just use the directory rules.

      This way the same executable will behave
      sensibly regardless of which environment it is
      on, and be able to open HERC01.FRED.C or
      HERC01/FRED.C. In the latter case, it will be
      PDOS that is adding the "HERC01/" implied
      directory prefix transparent to the executable
      itself (which thinks that profile noprefix is
      in force - because it is).

      BFN. Paul.
    • Gerhard Postpischil
      ... AFAIK, prefixing occurs only when the program explicitly does prefixing of unquoted data set names, or uses such in a DAIR request. It s my impression that
      Message 2 of 7 , Jul 6, 2011
      • 0 Attachment
        On 7/6/2011 7:53 AM, kerravon86 wrote:
        > I assume when a TSO program does an open of
        > fred.c that it knows that it needs to add the
        > SYSPREF on itself and do a dynalloc of it.
        > I'll thus need to add that functionality to
        > PDPCLIB.

        AFAIK, prefixing occurs only when the program explicitly does
        prefixing of unquoted data set names, or uses such in a DAIR
        request. It's my impression that SVC 99 requests don't prefix,
        but it's at least 30 years since I last looked at that (all SVC
        99 requests are unquoted names).

        Also when the TMP is run in batch, there generally is no
        requirement for the user to do a LOGON, and neither the user id
        nor prefix will be set (savvy programs use the job name as the
        user id if < 8 bytes).

        Whatever you do, the process should be consistent, so the user
        knows exactly what will happen to a request.

        Gerhard Postpischil
        Bradford, VT
      • kerravon86
        ... He s back! :-) ... Ok, so let s get it right for TSO for starters. The z/OS RECEIVE command is an example of a TSO CP that makes use of the prefix. I would
        Message 3 of 7 , Jul 6, 2011
        • 0 Attachment
          --- In hercules-os380@yahoogroups.com, Gerhard Postpischil <gerhard@...> wrote:

          He's back! :-)

          > On 7/6/2011 7:53 AM, kerravon86 wrote:
          > > I assume when a TSO program does an open of
          > > fred.c that it knows that it needs to add the
          > > SYSPREF on itself and do a dynalloc of it.
          > > I'll thus need to add that functionality to
          > > PDPCLIB.

          > Whatever you do, the process should be consistent, so the user
          > knows exactly what will happen to a request.

          Ok, so let's get it right for TSO for starters.

          The z/OS RECEIVE command is an example of a TSO CP
          that makes use of the prefix. I would like to be
          able to write my own RECEIVE using C/PDPCLIB.

          > AFAIK, prefixing occurs only when the program explicitly does
          > prefixing of unquoted data set names, or uses such in a DAIR
          > request. It's my impression that SVC 99 requests don't prefix,
          > but it's at least 30 years since I last looked at that (all SVC
          > 99 requests are unquoted names).

          Ok, so if SVC 99 requests don't prefix, but the
          TSO user has an expectation of prefixing when
          they run a CP, then it is reasonable that PDPCLIB
          has to prefix. So I'll need another assembler
          routine to obtain the prefix, and I'll call that
          assembler routine whenever it's a TSO environment
          and I need to do a dynalloc.

          > Also when the TMP is run in batch, there generally is no
          > requirement for the user to do a LOGON, and neither the user id
          > nor prefix will be set (savvy programs use the job name as the
          > user id if < 8 bytes).

          Running with a default noprefix has a predictable
          and expected result too.

          BFN. Paul.
        • Ray Mullins
          SVC 99 does not prefix, and there is no option to do so. However, in modern TSO, batch execution of IKJEFTxx will load the PROFILE info (nowadays from SAF).
          Message 4 of 7 , Jul 6, 2011
          • 0 Attachment
            SVC 99 does not prefix, and there is no option to do so.

            However, in modern TSO, batch execution of IKJEFTxx will load the PROFILE info (nowadays from SAF). The logon equivalent is done when the batch job enters the system.

            Sent via my/Envoyée par mon/Gesandt durch mein/Enviado para mi/meu iPhone

            On Jul 6, 2011, at 6:51, Gerhard Postpischil <gerhard@...> wrote:

            > On 7/6/2011 7:53 AM, kerravon86 wrote:
            >> I assume when a TSO program does an open of
            >> fred.c that it knows that it needs to add the
            >> SYSPREF on itself and do a dynalloc of it.
            >> I'll thus need to add that functionality to
            >> PDPCLIB.
            >
            > AFAIK, prefixing occurs only when the program explicitly does
            > prefixing of unquoted data set names, or uses such in a DAIR
            > request. It's my impression that SVC 99 requests don't prefix,
            > but it's at least 30 years since I last looked at that (all SVC
            > 99 requests are unquoted names).
            >
            > Also when the TMP is run in batch, there generally is no
            > requirement for the user to do a LOGON, and neither the user id
            > nor prefix will be set (savvy programs use the job name as the
            > user id if < 8 bytes).
            >
            > Whatever you do, the process should be consistent, so the user
            > knows exactly what will happen to a request.
            >
            > Gerhard Postpischil
            > Bradford, VT
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
          • Tony Harminc
            ... In TSO old and modern, forground or background, it s IKJPARS that normally does the prefixing, not Dynalloc or DAIR. You parse a dataset name on the
            Message 5 of 7 , Jul 6, 2011
            • 0 Attachment
              On 6 July 2011 10:28, Ray Mullins <catherdersoftware@...> wrote:
              > SVC 99 does not prefix, and there is no option to do so.
              >
              > However, in modern TSO, batch execution of IKJEFTxx will load the PROFILE info (nowadays from SAF). The logon equivalent is done when the batch job enters the system.

              In TSO old and modern, forground or background, it's IKJPARS that
              normally does the prefixing, not Dynalloc or DAIR. You parse a dataset
              name on the command line using IKJPOSIT, and if you want IKJPARS to
              stick the prefix on the front of the dsname you use the USID option.
              The advantage is that parse knows the rules, e.g. if you have a
              command FRED that takes a single dsname (more properly a dsthing if it
              can have *'s in it), then if your PROFILE PREFIX value is BLOGS, you
              might have:

              FRED CLIST
              which would return BLOGS.CLIST as the dsname,
              FRED *
              which would return just * since it knows not to prefix,
              FRED A.*.B
              which would return BLOGS.*.B ,
              FRED 'SYS1.CLIST'
              which would return SYS1.CLIST since it doesn't prefix an already quoted dsname.

              Actually there's a good bit more. Parse returns separate pointers to
              the dsname, the member name, and the password (does anyone remember
              those?), plus some flags showing if it was originally quoted.

              FRED (MEMB1)
              would return just a pointer to the member name MEMB1,
              *(MEMB1)
              would return a pointer to dsname * and member name MEMB1,
              A.*.B(MEMB1)/SECRET
              would return a pointer to dsname BLOGS.A.*.B, one to member MEMB1, and
              one to the password SECRET.

              And so on...

              Tony H.
            • kerravon86
              ... Why is this not prefixed? ... I think you meant BLOGS.A.*.B ... Ok, so if it s really being done properly, the TSO convention allows a password too. And
              Message 6 of 7 , Jul 6, 2011
              • 0 Attachment
                --- In hercules-os380@yahoogroups.com, Tony Harminc <tharminc@...> wrote:
                >
                > FRED *
                > which would return just * since it knows not to prefix,

                Why is this not prefixed?

                > FRED A.*.B
                > which would return BLOGS.*.B ,

                I think you meant BLOGS.A.*.B

                > A.*.B(MEMB1)/SECRET
                > would return a pointer to dsname BLOGS.A.*.B, one
                > to member MEMB1, and one to the password SECRET.

                Ok, so if it's really being done properly, the TSO
                convention allows a password too. And the expectation
                would be that the password is in turn passed on to
                SVC 99?

                The thing is that I might get the dataset name via
                prompting the user, ie "please enter filename". In
                that case, where I just have an input string, would
                you still recommend calling IKJPARS?

                And in the TSO programming environment, would you
                say it is frowned upon to roll your own prefixing
                rules and password scanner?

                And does IKJPARS internally call an SVC to do its
                scanning work? I'm a bit worried that "/" syntax
                will interfere with my intended use of directories,
                so would like to be able to choose to pass the /
                on to SVC 99 as part of the dataset name rather
                than being treated as a password.

                Thanks. Paul.
              • Tony Harminc
                ... The trite answer is that IKJPARS never prefixes a dsthing that starts with a *. But it makes sense, since the * has multiple meanings, e.g. to mean the
                Message 7 of 7 , Jul 6, 2011
                • 0 Attachment
                  On 6 July 2011 18:06, kerravon86 <kerravon86@...> wrote:
                  > --- In hercules-os380@yahoogroups.com, Tony Harminc <tharminc@...> wrote:
                  >>
                  >> FRED *
                  >> which would return just * since it knows not to prefix,
                  >
                  > Why is this not prefixed?

                  The trite answer is that IKJPARS never prefixes a dsthing that starts
                  with a *. But it makes sense, since the * has multiple meanings, e.g.
                  to mean the terminal on an ALLOCATE
                  ALLOC DD(SYSIN) DSN(*)
                  or as a wildcard of sorts on some commands.

                  >> FRED A.*.B
                  >> which would return BLOGS.*.B ,
                  >
                  > I think you meant BLOGS.A.*.B

                  Sorry - typo. There'll be more.

                  >> A.*.B(MEMB1)/SECRET
                  >> would return a pointer to dsname BLOGS.A.*.B, one
                  >> to member MEMB1, and one to the password SECRET.
                  >
                  > Ok, so if it's really being done properly, the TSO convention allows a password too.

                  Yes, although passwords have been moribund since RACF and such came
                  along. (This is not a UADS or RACF logon password, but an entry in the
                  greatly deprecated PASSWORD dataset.)

                  > And the expectation would be that the password is in turn passed on to SVC 99?

                  Yup.

                  > The thing is that I might get the dataset name via
                  > prompting the user, ie "please enter filename". In
                  > that case, where I just have an input string, would
                  > you still recommend calling IKJPARS?

                  If you prompt for a filename you should expect a file name. If you
                  prompt for a dataset name, expect that. But that's an aside...

                  TSO commands normally use IKJPARS to parse their command operands. If
                  the template supplied to parse is not satisfied by what the user
                  supplies, then parse will prompt.

                  READY
                  listd
                  IKJ56700A ENTER DATA SET NAME -
                  impossiblylong
                  IKJ56709I INVALID DATA SET NAME, impossiblylong
                  IKJ56703A REENTER THIS OPERAND -
                  clist
                  TONY.CLIST
                  --RECFM-LRECL-BLKSIZE-DSORG
                  FB 80 6160 PO
                  --VOLUMES--
                  TSO001
                  READY

                  So normally the user enters, and/or is prompted to enter and/or
                  correct all the input to the program before parse returns to the
                  caller. Then the program interprets the input, allocates datasets,
                  does its processing, and so on. It's not "normal" for the program
                  itself to prompt for input that would typically be supplied on the
                  command invocation, but certainly you can. The "official" thing to do
                  is issue the prompt with PUTGET, and then if the input is at all
                  complex you can use parse again, typically with a different template,
                  to figure out what the user entered. If it's something simple, you can
                  just do it yourself, of course.

                  A main point of parse is to keep things consistent, so that you don't
                  have each program parsing dsnames and such differently.

                  > And in the TSO programming environment, would you
                  > say it is frowned upon to roll your own prefixing
                  > rules and password scanner?

                  Well... There are (or were) purists, but they usually bumped into
                  something that parse didn't handle too well, and so ended up doing a
                  bit of it themselves. In recent years IBM has been a big offender
                  here.

                  > And does IKJPARS internally call an SVC to do its scanning work?

                  You can LINK to IKJPARS, or you can call it using an address in the
                  CVT. The latter will perform better, of course. To my knowledge it
                  doesn't issue further SVCs, except perhaps GETMAIN/FREEMAIN, and of
                  course TPUT via PUTGET, if needed. (The user can disable prompting via
                  PROFILE NOPROMPT if s/he wants it to fail rather than prompt.)

                  READY
                  prof noprompt
                  READY
                  listd
                  IKJ56701I MISSING DATA SET NAME
                  READY

                  > I'm a bit worried that "/" syntax
                  > will interfere with my intended use of directories,
                  > so would like to be able to choose to pass the /
                  > on to SVC 99 as part of the dataset name rather
                  > than being treated as a password.

                  If you want to use the thing predefined to parse as DSNAME (or
                  DSTHING, which allows the * stuff), then you are stuck with its rules
                  for that kind of object, which include a trailing password. If you
                  want to parse another kind of string, then you can define it in terms
                  of allowable characters, length, whether it is delimited or free form,
                  can occur multiple times, etc. etc. There are parse exits to add
                  further syntax checking if you like.

                  But do keep in mind that it is part of TSO command syntax that the
                  characters /* start a comment, and that any number of blanks, commas,
                  tabs, and /* comments */ are equivalent. It is really really annoying
                  to encounter a TSO command with home-grown parsing that doesn't
                  understand this, and applies rules from some other OS...

                  READY
                  listd clist status history
                  TONY.CLIST
                  --RECFM-LRECL-BLKSIZE-DSORG-CREATED---EXPIRES---SECURITY--DDNAME---DISP
                  FB 80 6160 PO 2009.132 00.000 RACF SYS00133 KEEP
                  --VOLUMES--
                  TSO001
                  READY
                  listd clist /* mild, isn't it? */ status,,,,history
                  TONY.CLIST
                  --RECFM-LRECL-BLKSIZE-DSORG-CREATED---EXPIRES---SECURITY--DDNAME---DISP
                  FB 80 6160 PO 2009.132 00.000 RACF SYS00134 KEEP
                  --VOLUMES--
                  TSO001
                  READY
                  listd clist /* this is not status, or history */
                  TONY.CLIST
                  --RECFM-LRECL-BLKSIZE-DSORG
                  FB 80 6160 PO
                  --VOLUMES--
                  TSO001
                  READY

                  Tony H.
                Your message has been successfully submitted and would be delivered to recipients shortly.