hey, it's MY laziness that prevents me from remembering exactly how Suprtool
deals with Are you allowed to see these items? prolly on page 1 of the
manual, sitting right here untouched since its receipt. Now THAT's good
software!
> -----Original Message-----
> From: Art Bahrs [mailto:[log in to unmask]]
> Sent: Wednesday, November 24, 2004 9:03 AM
> To: [log in to unmask]
> Subject: Re: Using the "@" list in TurboIMAGE
>
>
> Hi Tracy :)
> Ahhh... thanks for the correction :) I was thinking there was
> something else to it... but couldn't remember it... must be too much
> something or other :)
>
> Art "How long till the turkey is ready to eat? hehe" Bahrs
>
> =======================================================
> Art Bahrs, CISSP Information Security The
> Regence Group
> (503) 553-1425 FAX (503) 553-1453
>
>
> |---------+-------------------------------->
> | | "Tracy Pierce" |
> | | <[log in to unmask]
> | | rg> |
> | | |
> | | 11/24/2004 08:53 AM |
> | | |
> | | |-------------------||
> | | | [ ] Secure E-mail ||
> | | |-------------------||
> |---------+-------------------------------->
>
> >-------------------------------------------------------------
> -------------------------------------------------------------|
> |
> |
> | To: "[log in to unmask]"
> <[log in to unmask]>, "[log in to unmask]"
> <[log in to unmask]> |
> | cc:
> |
> | Subject: RE: Using the "@" list in TurboIMAGE
> |
>
> >-------------------------------------------------------------
> -------------------------------------------------------------|
>
>
>
>
> Suprtool clearly abides by Image Security at DBOPEN time, but
> what about
> when gathering data? Since its claim to fame is speed, achieved by
> bypassing Image almost entirely via MR NOBUF, it would likely
> have a bit of
> trouble skipping over Image items your particular password
> isn't supposed
> to
> see.
>
> The password changes you describe prevented your users from
> DBOPENing your
> base.
>
> Tracy Pierce
> > -----Original Message-----
> > From: Art Bahrs [mailto:[log in to unmask]]
> > Sent: Wednesday, November 24, 2004 8:35 AM
> > To: [log in to unmask]
> > Subject: Re: Using the "@" list in TurboIMAGE
> >
> >
> > Hi Tracy :)
> > I agree wholeheartedly with being lazy it is better :)
> >
> > I believe that SuprTool does actually follow the Image
> > security ...
> > IIRC when I changed the database schema to have new passwords
> > and rebuilt
> > the SRN databases away from the generic standard passwords
> > that SRN used a
> > bunch of things written for people stopped working right...
> > because they
> > used the 'readonly' passwords that I had changed... But the
> > jobs that used
> > the ';' and were logged on as the database creator and such
> > continued to
> > work...
> >
> > So, the moral probably is to write all jobs and command
> > files and such
> > to use only the necessary levels of passwords and not the God
> > passwords :)
> >
> > Art "thinking about it all over again... :) " Bahrs
> >
> > =======================================================
> > Art Bahrs, CISSP Information Security The
> > Regence Group
> > (503) 553-1425 FAX (503) 553-1453
> >
> >
> > |---------+-------------------------------->
> > | | "Tracy Pierce" |
> > | | <[log in to unmask]
> > | | rg> |
> > | | Sent by: "HP-3000 |
> > | | Systems Discussion" |
> > | | <[log in to unmask]
> > | | DU> |
> > | | |
> > | | |
> > | | 11/24/2004 07:56 AM |
> > | | Please respond to |
> > | | "Tracy Pierce" |
> > | | |
> > | | |-------------------||
> > | | | [ ] Secure E-mail ||
> > | | |-------------------||
> > |---------+-------------------------------->
> >
> > >-------------------------------------------------------------
> > -------------------------------------------------------------|
> > |
> > |
> > | To: [log in to unmask]
> > |
> > | cc:
> > |
> > | Subject: Re: [HP3000-L] Using the "@" list in
> > TurboIMAGE |
> >
> > >-------------------------------------------------------------
> > -------------------------------------------------------------|
> >
> >
> >
> >
> > Of Course you want to use copylibs!
> >
> > The laziness factor I mention is manifested in those copylib buffers
> > though:
> > in every shop I've ever worked, the copylib buffers
> > correspond to the @
> > ImageItemList. The simplicity of that method lets you
> > largely ignore the
> > lovely security tools built into Image.
> >
> > I always wanted to try, in cases such as HR or Payroll
> > databases, having
> > separate copylib'd buffers and ImageItemLists for various
> > Image usernames,
> > which would let you assign semi-sensitive programming
> > projects to people
> > who
> > have no business seeing particular data items, as long as you
> > protected the
> > schema and its passwords.
> >
> > I'm not sure what Suprtool's Edit would do with this; I'd be
> > willing to bet
> > that Mr Greer had the good sense to respect Image security.
> > But Suprtool
> > itself would probably choke - it really wants to ignore
> > security details in
> > exchange for speed.
> >
> > Tracy mixed emotions Pierce
> >
> >
> > > -----Original Message-----
> > > From: [log in to unmask] [mailto:[log in to unmask]]
> > > Sent: Tuesday, November 23, 2004 3:57 PM
> > > To: Tracy Pierce
> > > Cc: [log in to unmask]
> > > Subject: Re: [HP3000-L] Using the "@" list in TurboIMAGE
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi Tracy and All :)
> > > Actually, I was taught from day one to always put your
> > > record layouts
> > > in CopyLibs as it made updating and recompiling much easier
> > and clean.
> > > Also, you didn't go "I didn't think that program used that
> > > file?" near as
> > > much when you modify a file's record structure.
> > >
> > > Art "Remembering some of the tricks still" Bahrs
> > >
> > > =======================================================
> > > Art Bahrs, CISSP Information Security The
> > > Regence Group
> > > (503) 553-1425 FAX (503) 553-1453
> > >
> > >
> > > |---------+-------------------------------->
> > > | | "Tracy Pierce" |
> > > | | <[log in to unmask]
> > > | | rg> |
> > > | | Sent by: "HP-3000 |
> > > | | Systems Discussion" |
> > > | | <[log in to unmask]
> > > | | DU> |
> > > | | |
> > > | | |
> > > | | 11/23/2004 03:55 PM |
> > > | | Please respond to |
> > > | | "Tracy Pierce" |
> > > | | |
> > > | | |-------------------||
> > > | | | [ ] Secure E-mail ||
> > > | | |-------------------||
> > > |---------+-------------------------------->
> > >
> > > >-------------------------------------------------------------
> > > -------------------------------------------------------------|
> > > |
> > > |
> > > | To: [log in to unmask]
> > > |
> > > | cc:
> > > |
> > > | Subject: Re: [HP3000-L] Using the "@" list in
> > > TurboIMAGE
> |
> > >
> > > >-------------------------------------------------------------
> > > -------------------------------------------------------------|
> > >
> > >
> > >
> > >
> > > I think your way's correct, and I think the @ list was
> > > generally used as a
> > > lazy man's solution, worked around via compile-everything.
> > >
> > > There's no reason you can't put a specific item list in a copylib.
> > >
> > > Tracy (lazy as anybody) Pierce
> > >
> > > > -----Original Message-----
> > > > From: Adriana & Timothy Atwood [mailto:[log in to unmask]]
> > > > Sent: Tuesday, November 23, 2004 1:54 PM
> > > > To: [log in to unmask]
> > > > Subject: Re: Using the "@" list in TurboIMAGE
> > > >
> > > >
> > > > Nope, I never use "@". Everything at every shop were I had
> > > > any say over the
> > > > standards was done exactly as you describe. First an explicit
> > > > list then use
> > > > the "*" for current list.
> > > >
> > > > Works too. One of the systems I am currently looking after
> > > > has over 400
> > > > Cobol programs. I change databases to fulfill new
> > > > requirements all the time.
> > > > Never have to waste time recompiling hundreds of programs.
> > > >
> > > > As far as I am concerned, there is never any good reason to
> > > > use "@". List
> > > > processing overhead? If done as described so the lists are
> > > > only processed
> > > > once, I have never noticed any significant impact in list
> > > processing.
> > > >
> > > > ----- Original Message -----
> > > > From: "Walter Murray" <[log in to unmask]>
> > > > To: <[log in to unmask]>
> > > > Sent: Monday, November 22, 2004 9:17 PM
> > > > Subject: [HP3000-L] Using the "@" list in TurboIMAGE
> > > >
> > > >
> > > > > [My apologies if this is a duplicate for some readers. I
> > > > had trouble last
> > > > > week with some of my postings not making the jump through
> > > > the gateway to
> > > > > 3000-L.]
> > > > >
> > > > > When I learned IMAGE yea many years ago, I got the notion
> > > > that the right
> > > > way
> > > > > to call DBGET and related procedures was with an explicit
> > > > list parameter
> > > > > specifying the particular items of interest. If I was
> > > > concerned with the
> > > > > overhead of processing such a list, I could establish a
> > > > "current list",
> > > > > typically by doing a directed read to record 0 (which I
> > > > knew would return
> > > > > condition 12) and using "*;" in subsequent calls. The
> > > > theory was that, if
> > > > > there were structural changes to the database, such as new
> > > > items added to
> > > > > the dataset, it would not be necessary to change and
> > recompile any
> > > > programs
> > > > > that did not use the new items.
> > > > >
> > > > > In practice, however, it seems as though everybody just
> > > > uses "@;" all the
> > > > > time. The buffer layout gets put into a COPY library. If
> > > > items are added
> > > > > or modified, you have to track down every program that uses
> > > > that dataset
> > > > > and, at a minimum, recompile it. If you miss one,
> > > mysterious things
> > > > happen,
> > > > > as when the program's buffer becomes too short for the
> > > > newly enlarged
> > > > > dataset layout.
> > > > >
> > > > > Am I correct in my belief, based on admittedly limited
> > > > observation, that
> > > > > practically everybody always uses an "@;" list? If so, is
> > > > there any good
> > > > > reason for this? Is "@;" faster than "*;"? If so, why?
> > > > And is it enough
> > > > > faster to justify the risk and inconvenience of having to
> > > > recompile many
> > > > > programs whenever a minor structural database change is
> > > > made? Or am I
> > > > > missing something more significant?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Walter
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ----== Posted via Newsfeeds.Com -
> > > Unlimited-Uncensored-Secure Usenet
> > > > News==----
> > > > > http://www.newsfeeds.com The #1 Newsgroup Service in the
> > > > World! >100,000
> > > > Newsgroups
> > > > > ---= East/West-Coast Server Farms - Total Privacy via
> > > > Encryption =---
> > > > >
> > > > > * To join/leave the list, search archives, change list
> > settings, *
> > > > > * etc., please visit
> > http://raven.utc.edu/archives/hp3000-l.html *
> > > >
> > > > * To join/leave the list, search archives, change list
> settings, *
> > > > * etc., please visit
> http://raven.utc.edu/archives/hp3000-l.html *
> > > >
> > >
> > > * To join/leave the list, search archives, change list settings, *
> > > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> > >
> > >
> > >
> > >
> > >
> > > ==============================================================
> > > ================
> > > IMPORTANT NOTICE: This communication, including any
> > > attachment, contains information that may be confidential or
> > > privileged, and is intended solely for the entity or
> > > individual to whom it is addressed. If you are not the
> > > intended recipient, you should delete this message and are
> > > hereby notified that any disclosure, copying, or distribution
> > > of this message is strictly prohibited. Nothing in this
> > > email, including any attachment, is intended to be a legally
> > > binding signature.
> > > ==============================================================
> > > ================
> > >
> >
> > * To join/leave the list, search archives, change list settings, *
> > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> >
> >
> >
> >
> >
> > ==============================================================
> > ================
> > IMPORTANT NOTICE: This communication, including any
> > attachment, contains information that may be confidential or
> > privileged, and is intended solely for the entity or
> > individual to whom it is addressed. If you are not the
> > intended recipient, you should delete this message and are
> > hereby notified that any disclosure, copying, or distribution
> > of this message is strictly prohibited. Nothing in this
> > email, including any attachment, is intended to be a legally
> > binding signature.
> > ==============================================================
> > ================
> >
> > * To join/leave the list, search archives, change list settings, *
> > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> >
>
>
>
>
>
> ==============================================================
> ================
> IMPORTANT NOTICE: This communication, including any
> attachment, contains information that may be confidential or
> privileged, and is intended solely for the entity or
> individual to whom it is addressed. If you are not the
> intended recipient, you should delete this message and are
> hereby notified that any disclosure, copying, or distribution
> of this message is strictly prohibited. Nothing in this
> email, including any attachment, is intended to be a legally
> binding signature.
> ==============================================================
> ================
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
