Välkommen till - Data3

➔
ARTIKEL
mer kommer outputten som ASCII och inte som EBCDIC så du
måste konvertera för fortsatt processing där du använder RPG
eller CL program.
Tips # 4 Ta bort Directories och konstiga namn
Du manipulerar IFS directories och filer från OS/400 via den
interaktiva kommandot WRKLNK, Detta kommando låter dig
navigera i IFS:ens directory struktur och börjar med rooten(/),
om du inte specificerar ett start directory. Du kan kopiera, ta
bort, byta namn och titta på attribut på filerna. Tyvärr,
WRKLNK är inte så lätthanterlig när det gäller att ta bort directories
eller filer med konstiga namn, namn som har mellanslag
eller andra konstigheter i sig. Om du försöker ta bort sådana
directories som innehåller filer eller symboliska länkar kommer
ett meddelande enligt följande: ”Request cannot be completed
— directory contains objects.” Det blir samma sak om om du
försöker ta bort, kopiera eller byta namn på enskilda filer.
För att kunna ta bort directories som har innehåll gå först
upp en nivå och ta val 2=Edit to display för överliggande directory
vilket kommer att lista alla objekt där. Sedan använder du
val 9=Recursive delete för att ta bort de directory och alla subdirectories,
oavsett om de innehåller objekt eller inte.
Konstiga namn är fel för OS/400 och måste ha skapats av ett
icke OS/400 program. Namn med blanksteg, slashes eller andra
specialtecken kan inte tolkas korrekt av WRKLNK eller andra
OS/400 kommandon och det är ett stort problem när man skal
ta bort demDu kan ta bort dessa filer med kommandot QSH
RM (remove) genom att ange filnamnet mellan dubbla kvottecken.
Till exempel:
Qsh
Rm ”Konstiga fil Namn”
Om filnamnet innehåller dubbla kvottecken kan du klara dig
om du gör backslash före dem:
Rm ”Mel \”rotorhead\” Beckman”
12
Om det finns ASCII tecken som inte existerar I EBCDIC som
tilde(~) kan du använda dig av det hexadecimalt. För att ta bort
filen ”time~bandits” skulle du använda:
Rm ”time\x98bandits”
Tip ” 5 Regler för auktorisation
Inskränkningar i auktorisationen i IFS är något som du måste
förstå om du skall få IFS att spela bra till traditionella OS/400
applikationer.
IFS:en använder sig av auktorisationsregler som liknar Unixvärlden
och representeras av kollektiva flaggor för filer och
directory kallad ”mode of saccess”. Det finns tre typer av
access: Läs, Skriv och Kör. Kör flaggan har en dubbel funktion.
För en fil indikerar det att den kan köras som ett program; för
ett directory att den kan bli genomsökt.
För det mesta visar OS/400 flaggorna symboliskt som *
värde eller som en trekaraktärers sträng. Till exempel *RX,
detta menas läs och kör tillåtelse, *X är enbart tillåtet att exekvera.
Flaggorna lägger beslag en bit i ett binärt nummer som
kan komma fram som ett decimalt värde när man titta på den
på andra system (t. ex. via FTP) Det binära bit possitionen är
1xx för läs, x1x för skriv och xx1 för körflaggan.
Det finns tre olika tillåtelseflaggor: en för ägaren, en för ägarens
grup och en generell. Du kan översätta det med nyckelorden
*OWNER, *GROUP och *PUBLIC.
Det blir ofta problem när du försöker kopiera från en auktorisationssektor
till en annan. Till exempel när du kopierar en
OS/400 datafil till IFS med att använda kommandot CPY-
TOSTMF måste du ha *OBJMGT auktorisation för OS/400objektet
bara för att kommandot behöver få tag i source objektets
auktorisationsinformation – ägarnamn och ägaren
auktorisation – för att kunna mappa detta för att skapa en fil i
IFS. Om ett program saknar denna auktorisation kommer
CPYTOSTMF att misslyckas.
IFS kräver *RX tillåtelse till alla directories i sökvägen som
du vill läsa eller manipulera, men kräver bara *X tillåtelse för
samma sökväg för att navigera till directoryt via kommandot
CD eller chdir funktionen. Detta betyder att du kan navigera
till ett directory som du sedan finner att du är utan tillstånd at
läsa, lägga till eller ta bort filer i directoryt.
IFS ger tillåtelse för nya filer på ett ganska konstigt sätt som
många finner förvirrande. IFS sätter ägare och gruppnamn för
det nya objekten samma som ”parent directory” till directory
som har det nya objektet och inte till directoryt som objektet
ligger i som man kanske skulle kunna tänka sig.. Däremot
kommer *PUBLIC från det närmaste directoryt. Detta tillstånd
har den sidoeffekten att du kan skapa objekt som du sedan inte
har tillåtelse till.
Om dessa regler hade varit konsistent hade bara varit och
lärt sig hur den uppträder men individuella program kan ha
sina egna egenheter. Till exempel kopierar CPYTOSTMF bara
ägarauktorisation från en source OS/400 objekt. Den kopierar
inte gruppnamn eller auktorisation och sätter dessutom
*PUBLIC till 0 (no bits lika med *NONE). Windows och Unix
program accessar ett IFS directory från annat ställe och kan
göra egna saker också.
Meningen med detta tips är att få er att förstå hur IFS fungerar
när det gäller grundläggande tillåtelseregler och ”default”
och att alltid verifiera att det utförts som du har tänkt dig. De
flesta problem som uppstår med IFS:en har att göra med felaktig
autorisation.
Artikeln kommer från iSeries News
och är publicerad med tillåtelse från iSeries News.