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 *