CPYTOIMPF und MCH3402

[ILEMax]

In der Jobq ist nur ein Job erlaubt.

Da der Basis- und der Ziel-Dateiname in jedem Job anders ist, darf auch ein parallellauf diesen Fehler nicht verursachen.

Das schlimme ist ja, das der Befehl in Summe sich Fehlerfrei zurück meldet obwohl er nichts gemacht hat.
Dann können wir erst reagieren wenn der Empfänger sich beschwert, das er keine Daten bekommen hat.

[Fuerchau]

Wenn man sich die Meldung ansieht wird ja "CheckCredInternal..." aufgerufen.
Dies ist da wohl die Anmeldeprozedurt (Cred: Credential-Objekt für die Anmeldung), die fehlschlägt.
Das kann man aber prüfen, wenn man den, sonst unnötigen, MKDIR für den Pfad "/QNTC/Freigabe" noch mal aufruft.
Damit wird dann der Anmeldevorgang für den Jobuser noch mal wiederholt, was bei Wiederholung egal ist, aber wenn er fehlschlägt einen Hinweis bringt.

Schließlich sind IFS-Zugriffe ja nicht vererbbar. Es wird immer mit Jobuser und nicht Programm-Owner (adopted authority) zugegriffen.

Wenn das immer noch nicht hilft, kann man auch einen QSH-Befehl LS mit Ausgabe in eine Datei durchführen um die Verbindung zu prüfen. Alternativ klappt ggf. auch der neue SQL-Zugriff mit den IFS-Funktionen nach dem MKDIR.

[ILEMax]

Danke, aber nein! ich will da nicht hinterher programmieren. Natürlich kann man das 'irgendwie' umgehen, anschließend auf erfolg testen, nochmal machen, ....

Ich habe es abgegeben mit der Empfehlung IBM zu fragen.

@Holger
wir hatten und haben(teilweise) mit V7R5 massive Probleme rund um Zugriffe auf das /QNTC/
Die Samba Version verspringt nach reboot ab und an zurück auf 3, zugriffe werden abgelehnt, 10 Sekunden später funktionieren die, find, LS, netuse, und div. andere Befehle funktionieren mal, mal nicht. Einiges ist mit PTF behoben, einiges haben wir umgestellt. Viel unnötige Arbeit, wenn das Release hier nicht so schauerlich schlampig wäre.

der ILEMax

[Fuerchau]

Zugriffe auf QNTC kann auch durch Änderungen bei Microsoft problematisch sein, da IBM diesbezüglich schnell hinterherhinkt. Da reicht ein Securitypatch schon mal aus.
Allerdings kann man auf Windows auch Samba1, auch wenn es unsicher gilt, reaktivieren.

https://learn.microsoft.com/de-de/wi...v3?tabs=server

[ILEMax]

nicht, wenn der Gegner eine Isilon ist und die Sicherheit Prio 1 hat.

[Fuerchau]

Dann sollte man den Weg umdrehen, was sich in vielen Dingen als einfacher und sicherer dargestellt hat.
Denn Information ist eine Holschuld.
Auch wenn inzwischen das Pushen dauernd angeboten wird kann es ganz schön lästig sein.
Aber das ist eine Filosofie- bzw. Philosphiefrage.

[holgerscherer]

nicht, wenn der Gegner eine Isilon ist und die Sicherheit Prio 1 hat.

das passt nur bedingt zusammen. Dell EMC ist (wie manch andere Hersteller) berüchtigt dafür, alles klein zu kriegen.

[gwoe]

Es gibt definitiv nachvollziehbare Probleme in 7.5. Wir haben im Februar eine neu installierte S914 mit 128 GB Hauptspeicher und 6x 387 SSD mit neu installiertem 7.5 mit allen PTFs bekommen. Nach zwei Wochen haben wir als erste Anwendung die SOFTM DKS auf die Maschine gelegt. Lief alles schön und sehr schnell bis zum MZA (maschineller Zahlungsausgang). Hier wird im CL eine Datei in die QTEMP kopiert und ein nachfolgendes COBOL will sie lesen. Blieb nachvollziehbar immer an der Stelle mit einem MCH3402 stehen (Ausgangsprogramm setspaceptrfromptr). Aufregung in Österreich, IBM call : da gäbe es ein PTF für ein ähnliches Problem. War gerade mal zwei Tage alt, installiert : Problem bleibt.
Lösung : die DKS-Leute haben mir ein kundenindividuelles CL gemacht, das nach dem CPYF und vor dem COBOL-call ein DLY-5 enthält. Auch der Save 21 läuft immer wieder mal sporadisch auf einen MCH3402, wenn ein (jdes Mal ein anderes) IBM-internes Objekt gesichert werden soll.
Wenn man das CL selbst unter Kontrolle hat, sollte ein DLY vor jedem CPYTOIMPF helfen.

[holgerscherer]

Es gibt definitiv nachvollziehbare Probleme in 7.5. ...
Wenn man das CL selbst unter Kontrolle hat, sollte ein DLY vor jedem CPYTOIMPF helfen.

Das meinte ich mit Parallelisierung, gerade der CPYTOIMPF ist da ein Biest weil er ja schnell sein soll (Gruß nach Rochester). Zu "setspaceptrfromptr" gibt es einige Einträge...
Wenn von Interesse, sollten wir in Kontakt bleiben, da bald die erste Betaphase von 7.5+1 los geht. Und auf neuer Hardware wird das mit der Parallelisierung noch interessanter.

[holgerscherer]

Danke, aber nein! ich will da nicht hinterher programmieren. Natürlich kann man das 'irgendwie' umgehen, anschließend auf erfolg testen, nochmal machen, ....

Ich habe es abgegeben mit der Empfehlung IBM zu fragen.

@Holger
wir hatten und haben(teilweise) mit V7R5 massive Probleme rund um Zugriffe auf das /QNTC/
Die Samba Version verspringt nach reboot ab und an zurück auf 3, zugriffe werden abgelehnt, 10 Sekunden später funktionieren die, find, LS, netuse, und div. andere Befehle funktionieren mal, mal nicht. Einiges ist mit PTF behoben, einiges haben wir umgestellt. Viel unnötige Arbeit, wenn das Release hier nicht so schauerlich schlampig wäre.

der ILEMax

bin gerade in einer Konferenz mit IBM zum Thema Software Quality, die Meinungen sind verschieden, aber es wird wohl intern viel getestet.

Dafür kann man doch dank SWMA die IBM mit Tickets bombardieren oder zur not an CEAC Mitglieder senden.
Ist das erste mal, daß ich davon höre, und meist hat es Gründe. Aber dafür ist hier das Forum nicht geeignet, um ausführliche Logs zu posten.

/QNTC ist ein Problem, weil das SMB-Protokoll eine Katastrophe ist, und wie Baldur schrieb, die IBM hängt MS hinterher, und wenn andere Hersteller eine eigene Implementierung fahren,
dann sollte man auf FTP oder SCP gehen.